[lkml]   [1998]   [Feb]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 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

    > 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++){
    printf("%d\n", sum);

    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.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to

     \ /
      Last update: 2005-03-22 13:41    [W:0.024 / U:19.704 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site