> Tom Butts wrote: > > >User process fault: interruption code 0x7 > >CPU 0 > >Process insmod (pid:24 stackpage=008AB000) > >User PSW: 070de000 80442a60 Not tainted > >Followed by register sets [...] > > Well, don't leave out the interesting part ;-) > > This is seriously weird, I'd really like to see > the register contents and the User Code dump. > > Also interesting would be the results of > gdb /sbin/insmod > disass *0x442a60 > > Alan Cox wrote: > > >Thats a kernel crash. Are you sure you have matching oco and kernel ? > > Actually, this is a crash in user space (we dump a message > looking similar to a kernel crash when the debugging flag > is on ...). Notice the 'User process fault' ... > > Now why insmod would crash with a data exception is > really weird. This can either be a floating point > exception, but those are normally masked off unless > specifically requested by the application, or else > illegal operands of one of the 'decimal-operand' > instructions, but those are never generated by the > compiler ...
I'm sure they ARE generated, albeit incidentally. Consider this sequence of bytes 47f0 f846 0700 0600 The first byte is a four-byte branch instruction and might be generated by the C compiler The third byte is the start of a six-byte decimal instruction (ZAP) which is prone data exceptions. In Linux it could arise from buffer overflows, string format errrors - any of the bugs phreaks delight in exploiting. Not that I suggest that this arose from a deliberate action. Just don't be too surprised that you get decimal errors. -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Note: mail delivered to me is deemed to be intended for me, for my disposition.
