[DGD] DGD Segmentation Fault After Dump Restore
bart at wotf.org
bart at wotf.org
Sat Sep 21 14:07:14 CEST 2013
Forgot to mention, this is after a 'clean' start, so no restore from statedump
is involved.
Bart
On Sat, 21 Sep 2013 13:58:57 +0200, bart wrote
> Looks like I managed to trigger the same or a related issue.
>
> Can't reliably reproduce it, through it seems pretty much certain
> that recently upgraded LWOs are involved.
>
> Yesterday I changed a bit of code to use LWOs instead of clones as data
> objects for keeping track of some user data. As soon as I made that
> change, I started noticing intermittent crashes, usually after
> having done multiple recompiles of the master object for those LWOs,
> from what I can tell without actually referencing the LWOs
> inbetween. Haven't been able to narrow down the conditions more then
> that yet.
>
> Changing back to using clones makes the issue go away. That doesn't
> prove it is the LWOs but in my mind it makes it rather likely.
>
> Is there anything more I can do to help debug this issue?
>
> A backtrace follows, note that I gathered 4 different cores, showing
> 4 different backtraces, I can post backtraces from the other 3 as
> well if that would help.
>
> Core was generated by `driver'.
> Program terminated with signal 11, Segmentation fault.
> Reading symbols from /lib/libc.so.7...done.
> Loaded symbols for /lib/libc.so.7
> Reading symbols from
> /libexec/ld-elf.so.1...done. Loaded
> symbols for /libexec/ld-elf.so.1
>
> #0 0x08051004 in o_control (obj=0x0) at object.c:966
> 966 if (!(o->flags & O_MASTER)) {
>
> (gdb) bt
>
> #0 0x08051004 in o_control (obj=0x0) at object.c:966
> #1 0x080641fb in i_call (f=0xbfbfb078, obj=0x0, lwobj=0x2849fc84,
> func=0x28408fc0 "query_priv", len=10, call_static=0, nargs=0) at
interpret.c:3086
> #2 0x08095ebc in kf_call_other (f=0xbfbfb078, nargs=2) at std.c:189
>
> #3 0x080656a4 in i_interpret1 (f=0xbfbfb078, pc=0x28579b5f "\n\001?@") at
> interpret.c:2592
>
> #4 0x08063df8 in i_funcall (prev_f=0xbfbfb3a8, obj=Variable "obj" is not
> available.
> ) at interpret.c:2973
>
> #5 0x08065af3 in i_interpret1 (f=0xbfbfb3a8, pc=0x28579bee "\n\001") at
> interpret.c:2698
> #6 0x08063df8 in i_funcall (prev_f=0xbfbfb768, obj=Variable "obj" is not
> available.
> ) at interpret.c:2973
> #7 0x080642fe in i_call (f=0xbfbfb768, obj=0x28301278, lwobj=0x0,
> func=0x28407470 "query_wiz", len=9, call_static=0, nargs=1) at interpret.c:3106
> #8 0x08095ebc in kf_call_other (f=0xbfbfb768, nargs=3) at std.c:189
> #9 0x080656a4 in i_interpret1 (f=0xbfbfb768, pc=0x28554e8a
"\n\001?��") at
> interpret.c:2592
> #10 0x08063df8 in i_funcall (prev_f=0xbfbfba88, obj=Variable "obj" is not
> available.
> ) at interpret.c:2973
> #11 0x08065af3 in i_interpret1 (f=0xbfbfba88, pc=0x28595a6f "\n\001\030") at
> interpret.c:2698
> #12 0x08063df8 in i_funcall (prev_f=0xbfbfbe38, obj=Variable "obj" is not
> available.
> ) at interpret.c:2973
> #13 0x08065af3 in i_interpret1 (f=0xbfbfbe38, pc=0x28595b9b "\n\001\030") at
> interpret.c:2698
> #14 0x08063df8 in i_funcall (prev_f=0xbfbfc308, obj=Variable "obj" is not
> available.
> ) at interpret.c:2973
> #15 0x080642fe in i_call (f=0xbfbfc308, obj=0x28302284, lwobj=0x0,
> func=0x2858eae8 "expand_alias", len=12, call_static=0, nargs=1) at
> interpret.c:3106
> #16 0x08095ebc in kf_call_other (f=0xbfbfc308, nargs=3) at std.c:189
> #17 0x080656a4 in i_interpret1 (f=0xbfbfc308, pc=0x28584ddd
"\n\0031�e�\030")
> at interpret.c:2592
> #18 0x08063df8 in i_funcall (prev_f=0xbfbfc748, obj=Variable "obj" is not
> available.
> ) at interpret.c:2973
> #19 0x080642fe in i_call (f=0xbfbfc748, obj=0x28302180, lwobj=0x0,
> func=0x28418fd4 "receive_message", len=15, call_static=0, nargs=1)
> at interpret.c:3106
> #20 0x08095ebc in kf_call_other (f=0xbfbfc748, nargs=3) at std.c:189
> #21 0x080656a4 in i_interpret1 (f=0xbfbfc748, pc=0x285901c2
"?\232:?@�� \001")
> at interpret.c:2592
> #22 0x08065c22 in i_interpret1 (f=Variable "f" is not available.
> ) at interpret.c:2736
> #23 0x08063df8 in i_funcall (prev_f=0xbfbfca68, obj=Variable "obj" is not
> available.
> ) at interpret.c:2973
> #24 0x08065af3 in i_interpret1 (f=0xbfbfca68, pc=0x285901e5 "Z:?@�") at
> interpret.c:2698
> #25 0x08063df8 in i_funcall (prev_f=0x80b8f60, obj=Variable "obj" is not
> available.
> ) at interpret.c:2973
> #26 0x080642fe in i_call (f=0x80b8f60, obj=0x28301d70, lwobj=0x0,
> func=0x80a6cd0 "receive_message", len=15, call_static=1, nargs=1)
> at interpret.c:3106
> #27 0x0805d3b0 in comm_receive (f=0x80b8f60, timeout=0, mtime=281) at
comm.c:1578
> #28 0x0806a239 in dgd_main (argc=Variable "argc" is not available.
> ) at dgd.c:223
> #29 0x0809c15e in main (argc=Cannot access memory at address 0x0
> ) at local.c:46
>
> On Mon, 09 Sep 2013 19:19:57 +1000, Neil McBride wrote
> > Not sure if I'm on Felix's whitelist so posting this to the list too.
> >
> > On 9/09/2013 5:50 PM, Felix A. Croes wrote:
> > >> The statedump was likely corrupted. Was it by the same version of DGD,
> > >> or an earlier version? Also, could you email me the result of the commands
> > >>
> > >> frame 1
> > >> print *tmpl
> > >>
> > >> with this coredump?
> >
> > The state dump was from the same version of DGD. I restarted from a
> > fresh restart a few days ago when this originally happened thinking
> > perhaps it was me.
> >
> > Output from the above commands follow: -
> >
> > Core was generated by `./bin/driver H7/H7.dgd dump'.
> > Program terminated with signal 11, Segmentation fault.
> > #0 0x00007f4dc834a217 in o_control (obj=0x7f4dc9adb340) at object.c:966
> > 966 if (!(o->flags & O_MASTER)) {
> > (gdb) bt
> > #0 0x00007f4dc834a217 in o_control (obj=0x7f4dc9adb340) at object.c:966
> > #1 0x00007f4dc83592f9 in d_get_varmap (obj=0x7ffff35180b0, update=0,
> > nvariables=0x7ffff35180f4) at data.c:1521
> > #2 0x00007f4dc83597cf in d_upgrade_lwobj (lwobj=0x7f4dc8264d48,
> > obj=0x7f4dc96dc280) at data.c:1649
> > #3 0x00007f4dc8350672 in d_count (save=0x7ffff3518200,
> > v=0x7f4dc829a4f0, n=1)
> > at sdata.c:1830
> > #4 0x00007f4dc83503ed in d_arrcount (save=0x7ffff3518200,
> > arr=0x7f4dc827b0f0)
> > at sdata.c:1776
> > #5 0x00007f4dc8350599 in d_count (save=0x7ffff3518200,
> > v=0x7f4dc82ada88, n=3)
> > at sdata.c:1813
> > #6 0x00007f4dc83515a5 in d_save_dataspace (data=0x7f4dc8279378, swap=1
> > '\001')
> > at sdata.c:2210
> > #7 0x00007f4dc835215a in d_swapout (frag=32) at sdata.c:2437
> > #8 0x00007f4dc837415e in endthread () at dgd.c:89
> > #9 0x00007f4dc835e870 in comm_receive (f=0x7f4dc85f9b00 <topframe>,
> > timeout=26, mtime=827) at comm.c:1580
> > #10 0x00007f4dc837458a in dgd_main (argc=2, argv=0x7ffff351a5b0) at
> > dgd.c:223
> > #11 0x00007f4dc83c86dd in main (argc=3, argv=0x7ffff351a5a8) at local.c:46
> > (gdb) frame 1
> > #1 0x00007f4dc83592f9 in d_get_varmap (obj=0x7ffff35180b0, update=0,
> > nvariables=0x7ffff35180f4) at data.c:1521
> > 1521 vmap = o_control(tmpl)->vmap;
> > (gdb) print *tmpl
> > Cannot access memory at address 0x7f4dc9adb340
> >
> > Thanks,
> >
> > Neil.
> > ____________________________________________
> > https://mail.dworkin.nl/mailman/listinfo/dgd
>
> --
> http://www.flickr.com/photos/mrobjective/
> http://www.om-d.org/
>
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
--
http://www.flickr.com/photos/mrobjective/
http://www.om-d.org/
More information about the DGD
mailing list