Hi Arne, I'm curious about what you think it would take to merge the faster_calls branch to 8.1? Do you know about any outstanding issues or is it mostly about rebasing it to 8.1 head and running the testsuite?
Thanks, Marty > 24 apr. 2016 kl. 16:10 skrev Arne Goedeke <e...@laramies.com>: > > 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 >> >
