Assocative Array length causes segv when using base classes as key

[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]

[dnadlinger]

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?

[dnadlinger]

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

[dnadlinger]

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.

[dnadlinger]

Great, thanks!

[John-Colvin]

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

[dnadlinger]

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