pouët.net

...but i'm pretty certain such trickeries shouldn't count :)

gargaj: what do you mean, "valid code there"? it's no jump or anything, if it doesn't crash from loading an invalid selector, it just runs on (...and probably crashes later :)

fr33ke, changing segment registers isn't a privileged operation.

How about:

int main(){return main();}

Surely that's never optimized to a loop?

I think 1/0 anywhere would upset the compiler if it attempts to optimize.

haha.. this is becoming rocket science here.. :)
cool results..
i would vote for a tie (ryg and fr33ke)?! cause both solutions are cool and "somehow" do what they should on most systems..

Yeah, VC++ refuses to compile undefined constants. ;)

And isn't the thing about pop es that it corrupts the stack, not that it changes es?

crashes with vc++ in debug mode :P

doom, just popping something doesn't corrupt the stack, and since main() gets called from inside the c library, there's a valid return address on the stack, so you don't have a stack underflow either. you'd need to return afterwards to have problems with stack corruption, but fr33kes code just runs on... but then, the next two bytes are "00 00", which is the "add [eax],al" that most certainly also causes the crash in my variant where the variable is uninitialized .)

eh, my bad, for some reason i thought es was the code segment (doh!)

at least be fruitful and code the biggest loaderbar ever!

ryg: It does if you haven't popped anything. Ie. the function won't be able to load the return address off the stack if you've messed with the stack pointer. But then, that's based on the weird idea i for some reason had that "7" is a function that ends in a return instruction. So, good point there. ;)

Anyway, x86 must have an illegal opcode you could put there instead of "pop es", to trigger a guaranteed exception straight away. Or maybe just whatever "divide register by the immediate value 0" assembles to. It should fit in an int if I remember my x86.

st 7

assembles fine in AsmPro and does the job.

When run in WinUAE it actually crashes the emulator, not just the emulated Amiga. ;)

blueberry:

nice but it doesn't crash my version of winuae. :D sf 6 however does. :D

So the C version to crash an Amiga:

main = 1358430215;

My WinUAE survives both st 7 and sf 6 though. Anyway, I have to say, crashing the program, the operating system and the (virtual) machine in one instruction is pretty impressive.

hehe. nicely optimized =) .w ftw :D

That makes a lot more sense if you substitute popped for pushed. See apparently I'm high. :)

my two favorite ways to crash a computer in x86 assembly are:

CLI
HLT
= 2 bytes

POP CS
= 1 byte

$4AFC ??

poi: pop cs is 6 bytes since this is a source code compo. however, we can rephrase it as

since that is 5 bytes ;) same effect for db 99, but other db NNs survive without a crash.

main;

Compiles with gcc and crashes on quite many systems.

it doesnt crash, but.... die; (php)

rmeht - if you want to play that game...
<?$
parse error
<?f();?>
fatal error
<?for(;;)$t[]="";?>
out of memory error

I've yet to find something that'll actually crash the php interpreter though, at least in 5.2.5 :D

Ger: Oh, I didn't notice it was about source code size.

Blueberry's bit compiles fine in asmone 1.48 on e-uae; it doesn't crash e-uae however.

Of course it compiles fine. It's a valid instruction. ;) But yeah, I think he and Stingray need to upgrade their WinUAEs to an earlier version.