Bus error while building GST 3.2 on SPARC Linux

Hello,

I have an error while building GST 3.2 on SPARC Linux
(sparc-unknown-linux2.6.17.8-gnu-glibc2.3)

Here are the last log lines:

make[2]: Entering directory `/root/smalltalk-3.2'
./gst --no-user-files --kernel-dir "./kernel" --image gst.im -iQ /dev/null
make[2]: *** [gst.im] Bus error
make[2]: Leaving directory `/root/smalltalk-3.2'

So, the problem seems happens while compiling the initial smalltalk image.

I have searched through the mailing list archive about that kind of "Bus
error", and it seems that
they are triggered by faultly bytecode generation.

Is this a known issue with SPARC architecture? If so, is there a
work-around (such as deactivating some optimisations
of the compiler, or maybe the JIT entirely)?

Thanks,
Gabriel.


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 07/16/2010 08:46 PM, Gabriel Cuvillier wrote:
The JIT is not active by default.  A backtrace can help, you can try

   ./libtool --mode=execute gdb --args ./gst <rest of command line above>
   handle SIGSEGV noprint
   run
   bt

Also, can you try the latest git instead of 3.2?  I plan to release
3.2.1 in a few days.  I honestly don't believe it will improve the
situation, but just to be sure.

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Hi,

Here are the results of the backtrace:

Program received signal SIGBUS, Bus error.
[Switching to Thread 16384 (LWP 2541)]
_gst_mem_alloc (h=0x38fd8, sz=184) at alloc.c:222
222           blk->vSmall.free = mem->next;
(gdb) bt
#0  _gst_mem_alloc (h=0x38fd8, sz=184) at alloc.c:222
#1  0x20061054 in _gst_tenure_oop (oop=0x203bb888) at oop.c:736
#2  0x20062aac in tenure_one_object () at oop.c:1619
#3  0x20062a1c in queue_put (q=0x20113b38, src=0x244352c0, n=7) at
oop.c:1548
#4  0x200634f0 in _gst_copy_an_oop (oop=0x203d7d80) at oop.c:2066
#5  0x20063124 in scan_grey_pages () at oop.c:1844
#6  0x20062e60 in copy_oops () at oop.c:1752
#7  0x200620cc in _gst_scavenge () at oop.c:1226
#8  0x200b2390 in activate_new_context (size=17, sendArgs=1) at interp.c:829
#9  0x200a0e04 in _gst_send_message_internal (sendSelector=0x11, sendArgs=1,
    receiver=0x2040f028, method_class=0x83) at interp-bc.inl:306
#10 0x200a9fd4 in _gst_interpret (processOOP=0x2040efd8) at vm.def:713
#11 0x200b48dc in _gst_nvmsg_send (receiver=0x203e7118,
    sendSelector=0x203acf00, args=0x3f04f304, sendArgs=2) at interp.c:2271
#12 0x2008328c in _gst_va_msg_sendf (resultPtr=0x3f04f51c,
    fmt=0x200d9580 "%s %o value: %o value: %o", ap=0x3f04f510) at
callin.c:304
#13 0x20083b3c in _gst_msg_sendf (resultPtr=0x3f04f51c,
    fmt=0x200d9580 "%s %o value: %o value: %o") at callin.c:379
#14 0x200551a8 in install_method (methodOOP=0x2040efc8) at comp.c:2637
#15 0x2005127c in _gst_compile_method (method=0x293190, returnLast=false,
    install=true) at comp.c:922
#16 0x20041540 in parse_method (p=0x3f04f8e8, at_end=93) at gst-parse.c:1131
#17 0x2003fd24 in parse_class_definition (p=0x3f04f8e8, classOOP=0x2040e170,

Some kind of memory overwrite somewhere? Maybe this will help..

For info, I am using a legacy system with a low-end SPARC processor and
only 256Mb memory. I just wanted to test if a small GST/Seaside website
would work reasonably well on such system with limited resources.

Since Autotools on that system are quite old, I am not able to generate
the makefiles with the latest git version. So, I will
test the 3.2.1 when it will be released.

Thanks,
Gabriel.

Paolo Bonzini a écrit :

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 07/19/2010 08:58 PM, Gabriel Cuvillier wrote:
Can you try --disable-generational-gc?

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Yes, it works!

Something is getting wrong with the generational gc then..

Thanks,
Gabriel.
>
> Can you try --disable-generational-gc?
>
> Paolo
>


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

>> Can you try --disable-generational-gc?
>
> Yes, it works!
>
> Something is getting wrong with the generational gc then..

Adding Bruno, who is the other (and main) author of libsigsegv.

Here is the backtrace that Gabriel is seeing:

Program received signal SIGBUS, Bus error.
[Switching to Thread 16384 (LWP 2541)]
_gst_mem_alloc (h=0x38fd8, sz=184) at alloc.c:222
222           blk->vSmall.free = mem->next;
(gdb) bt
#0  _gst_mem_alloc (h=0x38fd8, sz=184) at alloc.c:222
#1  0x20061054 in _gst_tenure_oop (oop=0x203bb888) at oop.c:736
#2  0x20062aac in tenure_one_object () at oop.c:1619
#3  0x20062a1c in queue_put (q=0x20113b38, src=0x244352c0, n=7) at
oop.c:1548
#4  0x200634f0 in _gst_copy_an_oop (oop=0x203d7d80) at oop.c:2066
#5  0x20063124 in scan_grey_pages () at oop.c:1844
#6  0x20062e60 in copy_oops () at oop.c:1752
#7  0x200620cc in _gst_scavenge () at oop.c:1226
#8  0x200b2390 in activate_new_context (size=17, sendArgs=1) at interp.c:829
#9  0x200a0e04 in _gst_send_message_internal (sendSelector=0x11, sendArgs=1,
    receiver=0x2040f028, method_class=0x83) at interp-bc.inl:306
#10 0x200a9fd4 in _gst_interpret (processOOP=0x2040efd8) at vm.def:713
#11 0x200b48dc in _gst_nvmsg_send (receiver=0x203e7118,
    sendSelector=0x203acf00, args=0x3f04f304, sendArgs=2) at interp.c:2271
#12 0x2008328c in _gst_va_msg_sendf (resultPtr=0x3f04f51c,
    fmt=0x200d9580 "%s %o value: %o value: %o", ap=0x3f04f510) at
callin.c:304
#13 0x20083b3c in _gst_msg_sendf (resultPtr=0x3f04f51c,
    fmt=0x200d9580 "%s %o value: %o value: %o") at callin.c:379
#14 0x200551a8 in install_method (methodOOP=0x2040efc8) at comp.c:2637
#15 0x2005127c in _gst_compile_method (method=0x293190, returnLast=false,
    install=true) at comp.c:922
#16 0x20041540 in parse_method (p=0x3f04f8e8, at_end=93) at gst-parse.c:1131
#17 0x2003fd24 in parse_class_definition (p=0x3f04f8e8,
classOOP=0x2040e170,

It really looks like SPARC can send SIGBUS on an invalid memory access.

What do you think about unconditionally registering an handler for both
SIGSEGV and SIGBUS, basically dropping signals-*.h?

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Paolo,

> It really looks like SPARC can send SIGBUS on an invalid memory access.

For the record, the platform is Linux/SPARC.

> What do you think about unconditionally registering an handler for both
> SIGSEGV and SIGBUS, basically dropping signals-*.h?

I'm not a fan of catching unrelated signals.

Gabriel, can you try to
  1) Apply the attached patch to your copy of libsigsegv/ inside GNU smalltalk,
  2) Recompile GNU smalltalk,
  3) See whether it still crashes?

Paolo, is gst mmaping files, and the signal occurring when you are accessing
an area that is beyond the length of the file? Or does gst only use mmap of
anonymous memory?

Bruno


*** src/signals.h.orig Tue Jul 27 01:38:05 2010
--- src/signals.h Tue Jul 27 01:37:49 2010
***************
*** 18,21 ****
  /* List of signals that are sent when an invalid virtual memory address
     is accessed, or when the stack overflows.  */
  #define SIGSEGV_FOR_ALL_SIGNALS(var,body) \
!   { int var; var = SIGSEGV; { body } }
--- 18,21 ----
  /* List of signals that are sent when an invalid virtual memory address
     is accessed, or when the stack overflows.  */
  #define SIGSEGV_FOR_ALL_SIGNALS(var,body) \
!   { int var; var = SIGSEGV; { body } var = SIGBUS; { body } }

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 07/27/2010 01:43 AM, Bruno Haible wrote:
> Paolo, is gst mmaping files, and the signal occurring when you are accessing
> an area that is beyond the length of the file? Or does gst only use mmap of
> anonymous memory?

It is mmaping files, but the particular spot where the SIGBUS is
happening means that the area was anonymously mapped.  The mmaped file
includes object data which is not movable and is not reused when an
object inside there dies.  Instead oldspace is an anonymous mmap and it
is a full-blown memory heap with malloc (_gst_mem_alloc) and free
(_gst_mem_free).

> > What do you think about unconditionally registering an handler for both
> > SIGSEGV and SIGBUS, basically dropping signals-*.h?
>
> I'm not a fan of catching unrelated signals.

I agree, but it seems necessary (at least on SPARC/Linux).  Let's wait
for Gabriel's experiment.

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Paolo Bonzini wrote:
> It is mmaping files, but the particular spot where the SIGBUS is
> happening means that the area was anonymously mapped.  The mmaped file
> includes object data which is not movable and is not reused when an
> object inside there dies.  Instead oldspace is an anonymous mmap and it
> is a full-blown memory heap with malloc (_gst_mem_alloc) and free
> (_gst_mem_free).

Yes, it should be safe then.

Another reason for SIGBUS - on SPARC systems, never ocurring on x86 systems -
is an unaligned address, for example an 'ld' instruction on an address that
is not a multiple of 4, or an 'ldd' instruction on an address that is not a
multiple of 8 (e.g. if it crosses a page boundary...).

> Let's wait for Gabriel's experiment.

Yes. And it would be useful to see the values of 'blk', 'mem', and of the
CPU registers in
<http://lists.gnu.org/archive/html/help-smalltalk/2010-07/msg00017.html>.

Bruno

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Hello,

I have applied the patch, but problems are still here:

./gst --no-user-files --kernel-dir "./kernel" --image gst.im -iQ /dev/null
/root/smalltalk-3.2/kernel/File.st:225: Aborted
/root/smalltalk-3.2/kernel/File.st:225: Error occurred while not in byte
code interpreter!!
[0xffffffff]

Here is the result of the GDB session with the following commands :
-> handle SIGSEGV noprint
-> run
-> bt
-> x/4xw blk
-> x mem
-> info registers
-> x/184x h (just in case)

Don't hesitate to to ask for more

./libtool --mode=execute gdb --args ./gst --no-user-files --kernel-dir
"./kernel" --image gst.im -iQ /dev/null
GNU gdb 6.3-debian
This GDB was configured as "sparc-linux"...Using host libthread_db
library "/lib/libthread_db.so.1".
warning: not using untrusted file ".gdbinit"

(gdb) handle SIGSEGV noprint
Signal        Stop      Print   Pass to program Description
SIGSEGV       No        No      Yes             Segmentation fault

(gdb) run
Starting program: /root/smalltalk-3.2/.libs/lt-gst --no-user-files
--kernel-dir ./kernel --image gst.im -iQ /dev/null
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 21110)]
Program received signal SIGBUS, Bus error.
[Switching to Thread 16384 (LWP 21110)]
_gst_mem_alloc (h=0x38fd8, sz=184) at alloc.c:222
222           blk->vSmall.free = mem->next;

(gdb) bt
#0  _gst_mem_alloc (h=0x38fd8, sz=184) at alloc.c:222
#1  0x20061054 in _gst_tenure_oop (oop=0x203bb888) at oop.c:736
#2  0x20062aac in tenure_one_object () at oop.c:1619
#3  0x20062a1c in queue_put (q=0x20113b38, src=0x244352c0, n=7) at
oop.c:1548
#4  0x200634f0 in _gst_copy_an_oop (oop=0x203d7d80) at oop.c:2066
#5  0x20063124 in scan_grey_pages () at oop.c:1844
#6  0x20062e60 in copy_oops () at oop.c:1752
#7  0x200620cc in _gst_scavenge () at oop.c:1226
#8  0x200b2390 in activate_new_context (size=17, sendArgs=1) at interp.c:829
#9  0x200a0e04 in _gst_send_message_internal (sendSelector=0x11,
sendArgs=1, receiver=0x2040f028, method_class=0x83) at interp-bc.inl:306
#10 0x200a9fd4 in _gst_interpret (processOOP=0x2040efd8) at vm.def:713
#11 0x200b48dc in _gst_nvmsg_send (receiver=0x203e7118,
sendSelector=0x203acf00, args=0x3edb72f4, sendArgs=2) at interp.c:2271
#12 0x2008328c in _gst_va_msg_sendf (resultPtr=0x3edb750c,
fmt=0x200d9580 "%s %o value: %o value: %o", ap=0x3edb7500) at callin.c:304
#13 0x20083b3c in _gst_msg_sendf (resultPtr=0x3edb750c, fmt=0x200d9580
"%s %o value: %o value: %o") at callin.c:379
#14 0x200551a8 in install_method (methodOOP=0x2040efc8) at comp.c:2637
#15 0x2005127c in _gst_compile_method (method=0x293190,
returnLast=false, install=true) at comp.c:922
#16 0x20041540 in parse_method (p=0x3edb78d8, at_end=93) at gst-parse.c:1131
#17 0x2003fd24 in parse_class_definition (p=0x3edb78d8,
classOOP=0x2040e170, extend=false) at gst-parse.c:868
#18 0x2003f4fc in parse_scoped_definition (p=0x3edb78d8,
first_stmt=0x292c78) at gst-parse.c:523
#19 0x2003ed20 in parse_doit (p=0x3edb78d8, fail_at_eof=false) at
gst-parse.c:462
#20 0x2003e144 in parse_chunks (p=0x3edb78d8) at gst-parse.c:364
#21 0x2003df0c in _gst_parse_chunks () at gst-parse.c:341
#22 0x200488a8 in _gst_parse_stream (method=false) at lex.c:1186
#23 0x2007f190 in _gst_process_file (fileName=0x0, dir=2544312) at
input.c:846
#24 0x2003ccb0 in load_standard_files () at files.c:579
#25 0x2003c7d4 in _gst_initialize (kernel_dir=0x3edb7e75 "./kernel",
image_file=0x3edb7e86 "gst.im", flags=5) at files.c:521
#26 0x00011324 in main (argc=141312, argv=0x3edb7d44) at main.c:385

(gdb) x/4xw blk
0x24720000:     0x000000c0      0x00000000      0x00000055      0x0000003d

(gdb) x mem
0x46141ede:     Cannot access memory at address 0x46141ede

(gdb) info registers
g0             0x0      0
g1             0x3d     61
g2             0xe      14
g3             0x200f7308       537883400
g4             0x200fd828       537909288
g5             0x4f664e65       1332104805
g6             0x10     16
g7             0x20298060       539590752
o0             0x38fd8  233432
o1             0x24720000       611450880
o2             0x0      0
o3             0x0      0
o4             0x2168f248       560525896
o5             0x115000 1134592
sp             0x3edb6a80       0x3edb6a80
o7             0x2008b4e8       537441512
l0             0x46141ede       1175723742
l1             0x1c     28
l2             0x1      1
l3             0x38ff4  233460
l4             0x80     128
l5             0x0      0
l6             0x894a8000       -1991606272
l7             0x200fa7d8       537896920
i0             0x38fd8  233432
i1             0xb8     184
i2             0x1c     28
i3             0x3      3
i4             0x18     24
i5             0x201b308c       538652812
fp             0x3edb6ae8       0x3edb6ae8
i7             0x2006104c       537268300
y              0x0      0
psr            0x83     131
wim            0x0      0
tbr            0x0      0
pc             0x2008b648       0x2008b648 <_gst_mem_alloc+360>
npc            0x2008b64c       0x2008b64c <_gst_mem_alloc+364>
fsr            0x0      0
csr            0x0      0

(gdb) x/184x h
0x38fd8:        0x24738000      0x247cc000      0x247ec000      0x247e4000
0x38fe8:        0x247b0000      0x24718000      0x247e8000      0x24720000
0x38ff8:        0x24730000      0x2476c000      0x24748000      0x2471c000
0x39008:        0x24750000      0x2472c000      0x2473c000      0x24714000
0x39018:        0x247f0000      0x2479c000      0x00000000      0x2477c000
0x39028:        0x247a4000      0x00000000      0x00000000      0x246f8000
0x39038:        0x00000000      0x00000000      0x00000000      0x00000000
0x39048:        0x00000000      0x00000000      0x00000000      0x00000000
0x39058:        0x00000000      0x00000000      0x00000000      0x00000000
0x39068:        0x00000000      0x00000000      0x00000000      0x00000000
0x39078:        0x00000000      0x00000000      0x00000000      0x00000000
0x39088:        0x00000000      0x00000000      0x00000000      0x00000000
0x39098:        0x000fc000      0x00020000      0x00400000      0x0000003f
0x390a8:        0x00000008      0x00000038      0x00000007      0x00000000
0x390b8:        0x200612bc      0x20061280      0x20061374      0x000000f1
0x390c8:        0x00000000      0x00000000      0x00000000      0x00000000
0x390d8:        0x00000000      0x00000000      0x00000000      0x00000000
0x390e8:        0x00000000      0x00000000      0x00000000      0x00000000
0x390f8:        0x00000000      0x00000000      0x00000000      0x00000000
0x39108:        0x00000000      0x00000000      0x00000000      0x00000000
0x39118:        0x00000000      0x00000000      0x00000000      0x00000000
0x39128:        0x00000000      0x00000000      0x00000000      0x00000000
0x39138:        0x00000000      0x00000000      0x00000000      0x00000000
0x39148:        0x00000000      0x00000000      0x00000000      0x00000000
0x39158:        0x00000000      0x00000000      0x00000000      0x00000000
0x39168:        0x00000000      0x00000000      0x00000000      0x00000000
0x39178:        0x00000000      0x00000000      0x00000000      0x00000000
0x39188:        0x00000000      0x00020000      0x00400000      0x00000000
0x39198:        0x00000000      0x00000000      0x00000000      0x00000000
0x391a8:        0x200612bc      0x20061280      0x20061374      0x00000011
0x391b8:        0x3c009674      0x20279674      0x203b1f30      0x00000011
0x391c8:        0x3e0095ac      0x202795ac      0x203b2040      0x00000011
0x391d8:        0x3d3d00ac      0x202795ac      0x203b21b0      0x00000011
0x391e8:        0x3c009644      0x20279644      0x00000040      0x00000011
0x391f8:        0x3e0095ac      0x202795ac      0x00039fd8      0x00000011
0x39208:        0x7e3d0024      0x20279624      0x00000040      0x00000011
0x39218:        0x3c009614      0x20279614      0x00000040      0x00000011
0x39228:        0x3e0095ac      0x202795ac      0x00000000      0x00000011
0x39238:        0x3c0095c4      0x202795c4      0x00000000      0x00000011
0x39248:        0x3e0095ac      0x202795ac      0x00000010      0x00000011
0x39258:        0x3c0095ac      0x202795ac      0x00000000      0x00000011
0x39268:        0x3e0095c4      0x202795c4      0x00000000      0x00000011
0x39278:        0x3e3e00b4      0x202795b4      0x00000010      0x00000021
0x39288:        0x00000000      0x00000000      0x00039470      0x00000001
0x39298:        0x20113bd0      0x20113bd4      0x00000001      0x00000019
0x392a8:        0x00231528      0x246f8000      0x00001000      0x00000000

Good luck :)

Bruno Haible a écrit :

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 07/27/2010 07:18 PM, Gabriel Cuvillier wrote:
You need "handle SIGBUS noprint" too after applying the patch though.
This will provide a more interesting backtrace (and "x" command output).

Thanks,

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Gabriel Cuvillier wrote:
> _gst_mem_alloc (h=0x38fd8, sz=184) at alloc.c:222
> 222           blk->vSmall.free = mem->next;
>
> (gdb) x mem
> 0x46141ede:     Cannot access memory at address 0x46141ede

This value of 'mem' is unaligned, explaining the SIGBUS.

If it had been aligned, a SIGSEGV would have been generated, and
libsigsegv's handler would have been triggered. But since even after
filling in a memory page an unaligned address remains an unaligned address,
it would have been pointless to invoke libsigsegv's handler. So, there
is no need to change libsigsegv.

Bruno

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On Tue, Jul 27, 2010 at 23:27, Bruno Haible <[hidden email]> wrote:
> Gabriel Cuvillier wrote:
>> _gst_mem_alloc (h=0x38fd8, sz=184) at alloc.c:222
>> 222           blk->vSmall.free = mem->next;
>>
>> (gdb) x mem
>> 0x46141ede:     Cannot access memory at address 0x46141ede
>
> This value of 'mem' is unaligned, explaining the SIGBUS.

I'll investigate further, but I'm not sure this is the real value of
mem. It might be an artifact of debugging at -O2.  I'd trust it if I
saw a similar address in the sigsegv handler, of course.

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Gabriel Cuvillier wrote:
> Maybe it is not related, but I have a similar problem on that system when I
> try to compile CLISP, which is also using libsigsegv.
>
> With CLISP 2.49, I have the following error during the build of the initial image:
>
> ./lisp.run -B . -N locale -E UTF-8 -Epathname 1:1 -Emisc 1:1 -norc -m 2MW -lp  -x '(and (load "init.lisp") (sys::%saveinitmem) (ext::exit)) (ext::exit t)'
> make: *** [interpreted.mem] Segmentation fault

It is unrelated. CLISP also has a GC, with its own peculiar portability
problems and bugs.

You can report this on the clisp-list or clisp-devel list, though.

> I have tried to add -DNO_GENERATIONAL_GC, -DNO_TRIVIALMAP, -DNO_SINGLEMAP,
> and also tried to increase ulimits values. But nothing better.

clisp's unix/PLATFORMS file suggest as first thing to try: -DSAFETY=3.
Does this work?

Bruno

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk