1. tbone
  2. gdc fixes
  3. Issues
Issue #1 new

Segfault during gc_term

repo owner created an issue

{{{ Program received signal SIGSEGV, Segmentation fault. _D2gc3gcx3Gcx4markMFPvPvZv (this=@0x800c0e100, pbot=0x4171e6, ptop=0x527398) at ../../../libphobos/gc/gcx.d:2211 2211 auto p = cast(byte )(p1); Current language: auto; currently minimal (gdb) bt

0 _D2gc3gcx3Gcx4markMFPvPvZv (this=@0x800c0e100, pbot=0x4171e6, ptop=0x527398) at ../../../libphobos/gc/gcx.d:2211

1 0x000000000040c5ce in _D2gc3gcx3Gcx11fullcollectMFPvZm (this=@0x800c0e100, stackTop=0x7fffffffe698) at ../../../libphobos/gc/gcx.d:2442

2 0x000000000040cca9 in _D2gc3gcx3Gcx16fullcollectshellMFZm (this=@0x800c0e100) at ../../../libphobos/gc/gcx.d:2324

3 0x000000000040d921 in _D2gc3gcx2GC18fullCollectNoStackMFZv (this=@0x800c0d040) at ../../../libphobos/gc/gcx.d:1296

4 0x000000000040a934 in gc_term () at ../../../libphobos/gc/gc.d:131

5 0x000000000040f4ad in tryExec (dg={object = 0x7fffffffe790, func = 0x40f750 <runAll>}) at ../../../libphobos/rt/dmain2.d:482

6 0x000000000040f681 in _d_run_main (argc=<value optimized out>, argv=0x7fffffffe848, main_func=<value optimized out>) at ../../../libphobos/rt/dmain2.d:562

7 0x00000000004016ee in _start ()


At appears that the static data range added in rt.memory.initStaticDataGC() isn't correct. The root looks correct (&etext), but I think the end (&_end) is incorrect.

Looking at BoehmGC, it looks like they probe the whole image, since there could be holes in the range that are not accessible.

Comments (4)

  1. tbone reporter

    Yeah, I saw that, instead I am gonna query the kernel for a proper vm map of the process (similar to the D1 linux implementation which parses /proc/self/maps).

  2. tbone reporter

    I found a clean way to get memory map info in FreeBSD which will skip over the holes in the image (this will also be wanted if I ever tackle OpenBSD as well).

    I'd like to really write an API for the runtime for all OS specific functions, and have them implemented in C (so we can use the proper headers). What's your take on this Iain?

    It'd be similar to the way D1 was doing.

    Some of the functions I have in mind range from simple exposing of constants, eg.

    size_t __os_getPathMax(void)
        return PATH_MAX;

    to a little more complex ones like

    struct __os_vm_entry
       void* start;
       void* end;
       void* offset;
       ulong flags;
       char[PATH_MAX] path;
       // Maybe others?
    int __os_get_numVmEntries(size_t numrv);
    int __os_get_VmMap(__os_vm_entry* buf, size_t* bufsz);

    Then inside of the D code, we only ever call the os_* functions. For things like the GC, I think I'd make the code cleaner and easier to work on (and enhance) without having to do with a ton of conditionals inside of the D code.

    This would work for other things too, like getting the sizes of different system types, building enums in D, etc.

    This is specifically for the sys/* and machine/* headers, and less so for the libc ones (although there would be some benefit there too). A certain clean convention for this would enhance portability alot, at the price of maybe some runtime overhead which could be eliminated once gold and gcc-4.5 is working.

    Let me know what you think, and I'll see what I can come up with for cleaning up some of the GC stuff (which is my current issue I am working on).

    I can test on FreeBSD/i386, FreeBSD/x86_64, Linux/i386, Linux/x86_64, and maybe even win32/win64. I'd love to test on darwin/osx as well, but its kinda tough to get them running in an emulator. Solaris I'd be willing to do too, but Solaris is a fat pig running on bare metal, in an emulator its nearly useless.

  3. Log in to comment