GDB backtrace very high addRange sz #594
Comments
|
It still seems as though it isn't in line with the ElemSize printed with logInfo, I always get 2 now. The right size does seem to get through to gc.d - puzzling |
|
The right size is caught at gc.d, so this is just a GDB bug. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I started debugging with GDB today to make a layout for the commands a GC debugger should use and I'm getting outrageously high sizes for addRange in every call from memory.d
Breakpoint 2, core.memory.GC.addRange() (sz=1, p=0x875cc0) at src/core/memory.d:704
704 gc_addRange( p, sz );
(gdb) continue
Continuing.
Breakpoint 3, gc.gc.GC.addRange() (this=0x8f3100, sz=512720, p=0x875cc0) at src/gc/gc.d:1101
1101 if (!p || !sz)
(gdb) continue
Continuing.
Breakpoint 2, core.memory.GC.addRange() (sz=140737352996992, p=0x8ff520) at src/core/memory.d:704
704 gc_addRange( p, sz );
(gdb) backtrace
#0 core.memory.GC.addRange() (sz=140737352996992, p=0x8ff520) at src/core/memory.d:704
#1 0x00000000005048b4 in vibe.utils.memory.__T19FreeListObjectAllocTS4vibe4core7drivers9libevent28LevMutexVbi0Z.__T5allocZ.alloc() () at ../spee.d/externals/vibe.d/source/vibe/utils/memory.d:499
#2 0x00000000004d6235 in lev_alloc_mutex (locktype=0)
#3 0x00007ffff79a47f3 in event_global_setup_locks_ () from /lib64/libevent-2.0.so.5
#4 0x00000000004cabf4 in vibe.core.drivers.libevent2.Libevent2Driver.__ctor() (this=0x7ffff7ee5a00,
#5 0x00000000004c7e72 in vibe.core.core.setupDriver() ()
#6 0x00000000004c5d0a in vibe.core.core._sharedStaticCtor1() ()
#7 0x00000000004c60c9 in vibe.core.core.__modsharedctor() ()
#8 0x00000000005cbe88 in rt.minfo.__T14runModuleFuncsS442rt5minfo11ModuleGroup8runCtorsMFZ9__lambda2Z.runModuleFuncs() (this=0x8f3030, modules=...) at src/rt/minfo.d:345
#9 0x00000000005cbacc in rt.minfo.ModuleGroup.runCtors() (this=0xe) at src/rt/minfo.d:209
#10 0x0000000000582509 in rt.minfo.rt_moduleCtor() (this=0xffffffffffffffff, sg=0x8f3030)
#11 0x00000000005827db in rt.sections_linux.DSO.opApply() (dg=...) at src/rt/sections_linux.d:36
#12 0x00000000005824d5 in rt_moduleCtor () at src/rt/minfo.d:280
#13 0x000000000057f390 in rt_init () at src/rt/dmain2.d:166
#14 0x000000000057f712 in rt.dmain2._d_run_main() (this=0x4d621c <lev_alloc_mutex>)
#15 0x000000000057f6ce in rt.dmain2._d_run_main() (this=0x7fffffffe390, dg=...)
#16 0x000000000057f64f in _d_run_main (argc=1, argv=0x7fffffffe498, mainFunc=0x407f08 )
#17 0x000000000045c1d5 in main ()
(gdb) continue
I managed to reduce these significantly by replacing ElemSize with ElemSize.to!string.to!size_t
Breakpoint 1, core.memory.GC.addRange() (sz=2, p=0x900520) at src/core/memory.d:704
704 gc_addRange( p, sz );
(gdb) continue
Continuing.
Breakpoint 2, gc.gc.GC.addRange() (this=0x8f4100, sz=16, p=0x900520) at src/gc/gc.d:1101
1101 if (!p || !sz)
(gdb) continue
Continuing.
alloc Mutex/72
Breakpoint 1, core.memory.GC.addRange() (sz=2, p=0x900bb0) at src/core/memory.d:704
704 gc_addRange( p, sz );
(gdb) backtrace
#0 core.memory.GC.addRange() (sz=2, p=0x900bb0) at src/core/memory.d:704
#1 0x0000000000505010 in vibe.utils.memory.__T19FreeListObjectAllocTC4core4sync5mutex5MutexVbi0Z.__T5allocZ.alloc() () at ../spee.d/externals/vibe.d/source/vibe/utils/memory.d:498
#2 0x00000000004d677b in lev_alloc_mutex (locktype=0)
#3 0x00007ffff79a47f3 in event_global_setup_locks_ () from /lib64/libevent-2.0.so.5
#4 0x00000000004cb11c in vibe.core.drivers.libevent2.Libevent2Driver.__ctor() (this=0x7ffff7ee5a00,
#5 0x00000000004c839a in vibe.core.core.setupDriver() ()
#6 0x00000000004c6232 in vibe.core.core._sharedStaticCtor1() ()
#7 0x00000000004c65f1 in vibe.core.core.__modsharedctor() ()
#8 0x00000000005cc360 in rt.minfo.__T14runModuleFuncsS442rt5minfo11ModuleGroup8runCtorsMFZ9__lambda2Z.runModuleFuncs() (this=0x8f4030, modules=...) at src/rt/minfo.d:345
#9 0x00000000005cbfa4 in rt.minfo.ModuleGroup.runCtors() (this=0xe) at src/rt/minfo.d:209
#10 0x00000000005829e1 in rt.minfo.rt_moduleCtor() (this=0xffffffffffffffff, sg=0x8f4030)
#11 0x0000000000582cb3 in rt.sections_linux.DSO.opApply() (dg=...) at src/rt/sections_linux.d:36
#12 0x00000000005829ad in rt_moduleCtor () at src/rt/minfo.d:280
#13 0x000000000057f868 in rt_init () at src/rt/dmain2.d:166
#14 0x000000000057fbea in rt.dmain2._d_run_main() (this=0x4d6744 <lev_alloc_mutex>)
#15 0x000000000057fba6 in rt.dmain2._d_run_main() (this=0x7fffffffe390, dg=...)
#16 0x000000000057fb27 in _d_run_main (argc=1, argv=0x7fffffffe498, mainFunc=0x407f08 )
#17 0x000000000045c48d in main ()
I'm thinking passing enum to be implicitely converted to size_t is a bug. I haven't tested yet but I think this could be a cause of memory leaks.
The text was updated successfully, but these errors were encountered: