Skip to content

Loading…

Assocative Array length causes segv when using base classes as key #175

Closed
sumo opened this Issue · 8 comments

3 participants

@sumo

I get the following when I use a AA defined with the base class as key and derived classes added to it. I don't see this issue on DMD.

I haven't been able to produce a simple test case yet (the classes I am using are wrappers around the FFmpeg API) so I am happy to debug further with a little help on how to debug the _aaLen function.

/lib64/libpthread.so.0[0x3654a0efe0]
/lib/libphobos-ldc.so.60(_aaLen+0x1a)[0x7fa5794dd94a]
bin/Unittest/HW[0x41cec8]
bin/Unittest/HW[0x41c037]
bin/Unittest/HW[0x41f17f]
bin/Unittest/HW[0x41f399]
/lib/libphobos-ldc.so.60(+0x2c7bee)[0x7fa5794b6bee]
/lib/libphobos-ldc.so.60(_D2rt5minfo17moduleinfos_applyFMDFKPS6object10ModuleInfoZiZi+0x85)[0x7fa5794e1745]
/lib/libphobos-ldc.so.60(_D6object10ModuleInfo7opApplyFMDFKPS6object10ModuleInfoZiZi+0x1d)[0x7fa5794c876d]
/lib/libphobos-ldc.so.60(runModuleUnitTests+0xf8)[0x7fa5794b6938]
/lib/libphobos-ldc.so.60(+0x30e305)[0x7fa5794fd305]
/lib/libphobos-ldc.so.60(+0x30e25a)[0x7fa5794fd25a]
/lib/libphobos-ldc.so.60(main+0x18e)[0x7fa5794fd1ce]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x3654621735]
@klickverbot
LDC, the LLVM-based D compiler project member

Unfortunately, I don't have any good guess on what could be going on here, so giving you advice on where to look is a bit hard. However, if you just build your program and druntime with -g (which the latter is by default) and run it in GDB, where does the crash happen?

@sumo

Backtrace from GDB:

#0 0x00007ffff61e594a in aaLen (aa=...) from /lib/libphobos-ldc.so.60
#1 0x000000000041ec48 in object.__T16AssociativeArrayTiTC7streams12FFmpegStreamZ.AssociativeArray.length() (this=...) at /usr/include/d/ldc/object.di:461
#2 0x000000000041de37 in containers.inputcontainer.InputContainer.extractNextPacket() (this=0x7ffff4d65d80) at containers/inputcontainer.d:79
#3 0x0000000000422b95 in DecodeEncodeTest.DecodeEncodeTest.__ctor() (this=0x7ffff4d66e80) at integrationtests/DecodeEncodeTest.d:19
#4 0x0000000000422da9 in DecodeEncodeTest.__unittest1() () at integrationtests/DecodeEncodeTest.d:49
#5 0x00007ffff61bebee in core.runtime.runModuleUnitTests() () at runtime.d:350
#6 0x00007ffff61e9745 in rt.minfo.moduleinfos_apply() () at minfo.d:148
#7 0x00007ffff61d076d in object.ModuleInfo.opApply() () at object
.d:1838
#8 0x00007ffff61be938 in runModuleUnitTests () at runtime.d:340
#9 0x00007ffff6205305 in rt.dmain2.main() () at dmain2.d:555
#10 0x00007ffff620525a in rt.dmain2.main() () at dmain2.d:521
#11 0x00007ffff62051ce in main (argc=1, argv=0x7fffffffdf08) at projects/ldc/.:565
#12 0x0000003654621735 in __libc_start_main (main=0x408f60 main@plt, argc=1, ubp_av=0x7fffffffdf08, init=, fini=, rtld_fini=, stack_end=0x7fffffffdef8)
at libc-start.c:226
#13 0x00000000004094d9 in _start ()

Will I be able to debug ./dmd2/root/aav.c:_aaLen or is this code compiler only?

@klickverbot
LDC, the LLVM-based D compiler project member

Hm, are the FFmpeg bindings you mentioned available publicly? If so, could you put together a short (not necessarily minimal) test case?

@klickverbot
LDC, the LLVM-based D compiler project member

Oh, and yes, everything not in ldc/runtime (i.e. druntime and Phobos) is strictly compiler-only.

@sumo

Have to clean up the bindings and code so will post a test case once that is done.

@klickverbot
LDC, the LLVM-based D compiler project member

Great, thanks!

@John-Colvin

@sumo did you ever manage to get a test case for this?

@klickverbot
LDC, the LLVM-based D compiler project member

Closing for inactivity. The related code has changed quite a bit since.

@klickverbot klickverbot closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.