Messages in this thread | | | Date | Sat, 7 Feb 1998 13:01:43 +0100 (MET) | From | Gabriel Paubert <> | Subject | Re: Bus Errors! |
| |
On Sat, 7 Feb 1998, Suman_Saraf wrote:
> Sorry for the earlier goof up with the cd thing :-) What I was trying out > is :- > > This is a snip from man 7 signal > ---------------- > A SIGBUS is missing; this is because the 386 hardware does > not generate such a signal, but makes porting from other > architectures unnecessarily difficult. > ----------------
I don't have this on my man page.
> Then how come netscape dumps core with a bus error on my 386 running Linux > (when I try to access a Java Enables page)??
Are you using 2.0.x or 2.1.x ? I'll assume 2.0.x.
> I have upgraded my libc with gnumalloc() patch and now it is ok but what I > want to point out is how is a bus error generated in the 1st case on a 386 > machine when the man page says otherwise. > > And one more question: Do the later x86's generate this signal ?
You should be able to generate SIGBUS at will under 2.0.x.
From grep SIGBUS /usr/src/linux-2.0.*/arch/i386/kernel/traps.c DO_ERROR(11, SIGBUS,"segment not present", segment_not_present, current) DO_ERROR(12, SIGBUS,"stack segment", stack_segment, current) DO_ERROR(11, SIGBUS,"segment not present", segment_not_present, current) DO_ERROR(12, SIGBUS,"stack segment", stack_segment, current)
so SIGBUS corresponds to proccessor exceptions 11 (segment not present, which you can normally get only when allocating an ldt for wine) or 12 (stack fault), which is the interesting one. This last one may happen either when you try to load the SS register, which is not frequent or when you try to access the memory beyond the stack segment limit. This last one is easily generated when accessing an array on the stack with a wild pointer, but only when the machine instruction uses either %ebp or %esp as the base register to access this memory, otherwise you get exception 13 which translates to a SIGSEGV (oddities of the Intel architecture).
> As fas as my CS theory goes , bus error occurs when I try to access an int > on an odd location. This program dumps core with a bus error on HP-UX and > Solaris and not on Linux .
It depends on the underlying hardware, some machines (including all Intel) perform unaligned memory access with only some speed penalty, unless you enable a special feature of 486+ called alignment check (which will trigger a SIGSEGV on unaligned accesses BTW). Most RISC machines will trap on any unaligned access, although in some cases the access will be transparently emulated by low level software, but at a considerable cost in speed.
> Any pointers would be greatly appreciated. > > Also I would like to know , has anyone ever come across a program on Linux > which dumps core with a SIG_BUS other than netscape ?? >
Try the following example, compile it with cc sigbus.c -O2 -fomit-frame-pointer. Note that if you remove asm("ebp"), the compiler will likely allocate a different register and you'll get a SIGSEGV, my compiler is bleeding edge egcs but it should not make a difference on such a simple code:
/* sigbus.c */ #include <stdio.h> #include <string.h>
int main() { int array[10]; int i, sum=0; register int *p asm("ebp")=array; for(i=0; i<1000000; i++){ sum+=*p++; } printf("%d\n", sum); exit(0); }
conclusion, the SIGBUS is probably a wild index into an on stack array or something similar. Note that I don't think that you can trigger it as easily under 2.1.x because the segment limits are 4Gb which essentially disables protection through segmentation (and accessing a non presnt page triggers a SIGSEGV), but I don't have an Intel 2.1.x machine up right now. Don't ask me why very similar causes give different signals, I don't have the slightest idea.
Gabriel.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |