Opened 16 years ago
Closed 16 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: | ||
| 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)
Change History (16)
by , 16 years ago
| Attachment: | kdl-invalid-opcode.png added |
|---|
by , 16 years ago
| Attachment: | kdl-invalid-opcode-max-line-length.png added |
|---|
by , 16 years ago
| Attachment: | kdl-invalid-opcode-max-line-length-bt.png added |
|---|
comment:1 by , 16 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?
follow-up: 6 comment:2 by , 16 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 , 16 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:5 by , 16 years ago
comment:6 by , 16 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 , 16 years ago
comment:8 by , 16 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 , 16 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 , 16 years ago
That was "Invalid Opcode Exception" of course (my fingers had a mind of their own).
comment:11 by , 16 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 , 16 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.
bt of invalid opcode kdl