Opened 11 years ago

Closed 11 years ago

#2522 closed bug (fixed)

KDL - invalid opcode

Reported by: scottmc Owned by: axeld
Priority: normal Milestone: R1
Component: - General Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

This happened with hrev26404, but I've seen it happen with a couple different images build in the past week or so. Usually happens sometime during a ./configure, sometimes when checking assert.h, sometimes when finding the max commandline length. Attached are screenshots from a couple different crashes.

Attachments (3)

kdl-invalid-opcode.png (87.8 KB ) - added by scottmc 11 years ago.
kdl-invalid-opcode-max-line-length.png (105.1 KB ) - added by scottmc 11 years ago.
kdl-invalid-opcode-max-line-length-bt.png (77.1 KB ) - added by scottmc 11 years ago.
bt of invalid opcode kdl

Download all attachments as: .zip

Change History (16)

by scottmc, 11 years ago

Attachment: kdl-invalid-opcode.png added

by scottmc, 11 years ago

bt of invalid opcode kdl

comment:1 by emitrax, 11 years ago

This one has just happened to me too, while running the configure of bonnie++ which I've ran already many times with no problems. The only difference this time is that I was doing another operation that required I/O (e.g. wget).

The command called by the configure that causes the invalid opcode seems to be sed, although bt would return sh being the thread causing the crash.

Any suggestions about what I can check if it happens again?

comment:2 by stippi, 11 years ago

The previous BFS and file map bugs could corrupt the file system and file contents quite badly. Are you doing this with a completely fresh image? I could imagine that garbage was either in executable code, or libraries or something like that in such a way that it would still load, but then contained bad instructions. Could this be the case? I don't know what is needed to trigger this panic. Maybe the kernel itself or a driver contained such garbage?

comment:3 by scottmc, 11 years ago

"The previous BFS and file map bugs could corrupt the file system" Define previous.. Do you know about when that was, as this bug just showed up recently and if related to the "BFS and file map bugs" you refer too, if those are fixed that could very well have been the cause of this issue. I haven't run into the invalid opcode in the last few days, but then again I haven't been stressing the system. I do suspect that files were getting corrupted or just that the autotools hate me...

comment:4 by anevilyak, 11 years ago

That one was fixed in hrev26531 specifically.

comment:5 by scottmc, 11 years ago

I've been using hrev26547 for awhile now without seeing this issue or the one reported in #2523 so I suppose we can close both of these and if they show back up we'll just reopen them, but it seems to be fixed.

in reply to:  2 comment:6 by emitrax, 11 years ago

Replying to stippi:

The previous BFS and file map bugs could corrupt the file system and file contents quite badly. Are you doing this with a completely fresh image? I could imagine that garbage was either in executable code, or libraries or something like that in such a way that it would still load, but then contained bad instructions. Could this be the case? I don't know what is needed to trigger this panic. Maybe the kernel itself or a driver contained such garbage?

I've always use fresh vmware image, so I don't think it's related. I'll see if I manage to trigger it again.

comment:7 by scottmc, 11 years ago

This one still happens in hrev26573 as well, so it wasn't fixed by hrev26531 afterall.

comment:8 by bonefish, 11 years ago

Unfortunately I haven't seen this one yet. The stack trace looks like something went wrong on the stack. The eip at which the exception occurred is a location on the stack. And the 0xffff0104, which is the address through which syscalls are routed is displayed as a stack frame address. Either the stack is corrupted by something or the stack/stack frame pointers are offset.

It might give some more insight, if you could enable kernel tracing for syscalls and signals and also do a "traced 0" when it happens the next time. Maybe it even stops happing then with syscall tracing enabled, which would indicate a bug in the syscall handler code.

comment:9 by umccullough, 11 years ago

Aha! I didn't see this ticket (i searched for "Invalid Opencode Exception" and this bug didn't come up).

I am also seeing this when running ./configure on some libs and packages while messing with Haiku.

I'm currently running hrev26688 and have seen at least one or two of these in the last 24 hours.

Perhaps I'll add some tracing myself and see if I can provide extra detail.

These weren't happening two weeks ago when I was compiling all the same libs/packages before.

comment:10 by umccullough, 11 years ago

That was "Invalid Opcode Exception" of course (my fingers had a mind of their own).

comment:11 by bonefish, 11 years ago

This bug has a good chance of having been fixed in hrev26810. Since I've been able to reproduce it (actually haven't even seen it), I can't say that for sure, though. So I'm leaving it open for the time being. Please update, if you encounter it again, or if you don't.

comment:12 by scottmc, 11 years ago

Go ahead and close this. I've been kicking hrev26943 and have yet to see this one show up, so it's probably been fixed as well.

comment:13 by bonefish, 11 years ago

Resolution: fixed
Status: newclosed

Thanks for the feedback!

Note: See TracTickets for help on using tickets.