This fatal is actually also happening in usual pike 8.1, so i guess its unrelated to the new branch. The fatal happens during cleanup on exit, should that not make sure that things are cleaned up in the correct order? Or should the check be disabled on the final gc run when all objects are freed?
arne On 04/23/16 16:10, Arne Goedeke wrote: > I have been able to fix a couple of bugs in the branch by now. There are > some left, which I could use some help to understand why they occur. One > is triggered by the DHT.test in the bittorrent library. When running > that test in the 'faster_calls' branch with debug enabled, the following > fatal occurs: > > ------ > /home/el/code/rw/pike/src/gc.c:3864: GC fatal: > GC destructed parent prematurely. > **Block: 0x7f0d52594180 Type: object Refs: 5 > **Got gc marker at 0x753e010: flags=0x20001e refs=4 weak=2 xrefs=0 > saved=4 frame=0x61b1d80 [data=0x7f0d52594180 rf_flags=0x95 prev=(nil) > next=0x61b1d48 cycle_id=0x61b1d80 cycle_piece=0xffffffffffffffff > link_top/last_cycle_piece=0xffffffffffffffff] > **Parent identifier: 20 > **Program id: 66099 > **Object variables: > ** rtt: mixed name: state off: 56 value: 1 > ** rtt: mixed name: ping_fails off: 72 value: 0 > ** rtt: mixed name: last_ping off: 88 value: 1461419197 > ** rtt: mapping name: pings_inflight off: 104 value: mapping > of size 0 > ** rtt: mixed name: last_response off: 112 value: 1461419362 > ** rtt: mixed name: check_node_callout off: 128 value: array of > size 1 > ** === In inherit "Node", program 66100: > ** rtt: string name: node_id off: 16 value: > "O\366\355\207%n\277j4fI\323\231;\332|9Vu\30" > ** rtt: string name: address off: 24 value: "127.0.0.1" > ** rtt: string name: token off: 32 value: > "\370\373S\252""5\336\322\25\312[\205\201qR3h]\235z\311" > ** rtt: mixed name: port off: 40 value: 7010 > **Describing program 0x20fd070 of object: > **Got gc marker at 0x76c8cb0: flags=0x0000e refs=15106 weak=0 xrefs=0 > saved=15106 frame=(nil) > **Program id: 66099, flags: 308f, parent id: 66097 > **Location: > /home/el/local/pike/8.1.4/lib/modules/Protocols.pmod/Bittorrent.pmod/DHT.pike:601 > **Object got a parent. > ******************* > Pike was in GC stage 400 when this fatal occurred. > Backtrace at time of fatal: > > Subprocess died of signal SIGABRT. > ------ > > So apparently the parent object was destructed before its child. Does > anyone have any ideas what parts of the function call part in > interpret.c might be incorrect? Is the PARENT_CLONE case wrong? > > Thanks > > Arne >
