GST segfaults when running under GDB

Hi,

I'm trying to refresh my knowledge of GST internal workings.
I compiled the most recent master from git.

When run it normally (gst -i) it runs just fine.
When trying to run under GDB, it crashes on segmentation
fault. Details below.

Is it normal? If so, do I have to setup GDB specially or
compile GST specially to be able to debug it?
Any help is appreciated!

Best, Jan

-----------------------------------
Backtrace from GDB:
(gdb)
exec-file /home/jv/Projects/GNUSmalltak/sources/smalltalk/dist/bin/gst
(gdb) r -i
Starting
program: /home/jv/Projects/GNUSmalltak/sources/smalltalk/dist/bin/gst -i
[Thread debugging using libthread_db enabled]
Using host libthread_db library
"/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
_gst_mem_alloc (h=0x61d250, sz=296) at alloc.c:226
226      blk->vSmall.avail--;
(gdb) bt 30
#0  _gst_mem_alloc (h=0x61d250, sz=296) at alloc.c:226
#1  0x00007ffff7b2796e in _gst_tenure_oop (oop=0x61d250) at oop.c:756
#2  0x00007ffff7b27a65 in tenure_one_object () at oop.c:1624
#3  queue_put (q=0x7ffff7dd4c68 <_gst_mem+104>,
src=src@entry=0x7fffee4fcec8, n=<optimized out>) at oop.c:1554
#4  0x00007ffff7b28309 in _gst_copy_an_oop (oop=0x7fffee6462f0) at
oop.c:2064
#5  0x00007ffff7b29932 in scan_grey_pages () at oop.c:1851
#6  copy_oops () at oop.c:1759
#7  _gst_scavenge () at oop.c:1227
#8  0x00007ffff7b29d45 in _gst_alloc_obj (size=size@entry=312,
p_oop=p_oop@entry=0x7fffffffd9f8) at oop.c:789
#9  0x00007ffff7b1c932 in instantiate_numbytes (numBytes=312,
instanceSpec=<optimized out>, p_oop=0x7fffffffd9f8,
class_oop=0x7fffee5926a0) at dict.inl:719
#10 instantiate_with (p_oop=0x7fffffffd9f8, numIndexFields=<optimized
out>, class_oop=0x7fffee5926a0) at dict.inl:779
#11 method_new (class=0x7fffee66fba0, methodDesc=0x7fffee670410,
bytecodes=0x623fa0, literals=0x7fffee6703e0, header=...) at comp.c:2725
#12 _gst_make_new_method (numArgs=<optimized out>, numTemps=<optimized
out>, numTemps@entry=6, maximumStackDepth=<optimized out>,
maximumStackDepth@entry=5,
    attributesOOP=attributesOOP@entry=0x7fffee6703f0,
literalsOOP=literalsOOP@entry=0x7fffee6703e0, bytecodes=0x623fa0,
bytecodes@entry=0x61fe60, class=0x7fffee66fba0,
    selector=0x7fffee5919f0, categoryOOP=0x7fffee670390, startPos=16113,
endPos=17294) at comp.c:2702
#13 0x00007ffff7b1e1d8 in _gst_compile_method (method=0x626f80,
returnLast=returnLast@entry=false, install=install@entry=true,
undeclaredTemps=undeclaredTemps@entry=false)
    at comp.c:838
#14 0x00007ffff7b10733 in parse_method (p=p@entry=0x7fffffffdeb0,
at_end=at_end@entry=93) at gst-parse.c:1359
#15 0x00007ffff7b10ebd in parse_scoped_method (p=p@entry=0x7fffffffdeb0,
classOOP=classOOP@entry=0x7fffee66fc50) at gst-parse.c:1154
#16 0x00007ffff7b118d8 in parse_class_definition
(p=p@entry=0x7fffffffdeb0, classOOP=0x7fffee66fc50,
extend=extend@entry=false) at gst-parse.c:1014
#17 0x00007ffff7b12363 in parse_scoped_definition (first_stmt=0x620200,
p=0x7fffffffdeb0) at gst-parse.c:691
#18 parse_doit (p=p@entry=0x7fffffffdeb0,
fail_at_eof=fail_at_eof@entry=false) at gst-parse.c:624
#19 0x00007ffff7b128ad in parse_chunks (p=p@entry=0x7fffffffdeb0) at
gst-parse.c:475
#20 0x00007ffff7b12cf8 in _gst_parse_chunks
(currentNamespace=currentNamespace@entry=0x0) at gst-parse.c:449
#21 0x00007ffff7b14878 in _gst_parse_stream
(currentNamespace=currentNamespace@entry=0x0) at lex.c:1209
#22 0x00007ffff7b3f2cf in _gst_process_file
(fileName=fileName@entry=0x7ffff7b82be2 <standard_files+1186>
"AnsiDates.st", dir=dir@entry=GST_DIR_KERNEL) at input.c:855
#23 0x00007ffff7b0c063 in load_standard_files () at files.c:580
#24 _gst_initialize (kernel_dir=<optimized out>, image_file=<optimized
out>, flags=<optimized out>) at files.c:522
#25 0x00007ffff7b0b4f5 in gst_initialize (kernel_dir=<optimized out>,
image_file=<optimized out>, flags=<optimized out>) at gstpub.c:156
#26 0x00000000004010d3 in main (argc=<optimized out>, argv=<optimized
out>) at main.c:386
(gdb)

System (stock Debian testing):
uname -a
Linux sao 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt4-3 (2015-02-03) x86_64
GNU/Linux
jv@sao:~/Projects/gdb/sources1/gdb$ gcc --version

gcc (Debian 4.9.1-19) 4.9.1
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

gdb -version
GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show
copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".

(same behaviour also when using hand-baked gdb 7.9.40)

gst compiled as follows:
./configure --prefix=$PWD/dist
make
make install


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

On Sat, Feb 28, 2015 at 02:42:27PM +0000, Jan Vrany wrote:
> Hi,

Hi!

> Is it normal? If so, do I have to setup GDB specially or
> compile GST specially to be able to debug it?

Yes that is normal. For the incremental/generational garbage
collection one needs to know which objects changed since the
last operation. The classic way is to have a read/write barrier
(e.g. keep track everytime a pointer is followed to another
object). The approach Paolo picked was to use mprotect on the
pages the object is allocated.

This means that a SIGSEGV will be generated on these objects
and the garbage collector remembers it.

a.) In gdb you can do:

handle SIGSEGV nostop noprint
b abort
b exit

b.) You can compile GST with another GC and/or in libgst/oop.h
force "NO_SIGSEGV_HANDLING"



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

On Sat, 2015-02-28 at 18:35 +0100, Holger Hans Peter Freyther wrote:
Ah, yes, I know that. Stupid me, just did not think of it in
this case. Sorry!

>
> a.) In gdb you can do:
>
> handle SIGSEGV nostop noprint
> b abort
> b exit
>
> b.) You can compile GST with another GC and/or in libgst/oop.h
> force "NO_SIGSEGV_HANDLING"

I'd prefer the former than differently compiled VM.
Thanks a lot!

Best, Jan



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

        Can be friends?
My hobbies are games, hoping to play the game together!
______________________
i like the  RS Gold  at  rsgoldfast