I currently get the following with Pike 8.1 with debug:
nilsson@carbon:~/pike/dmalloc$ make run_hilfe /home/nilsson/pike/dmalloc/pike -DNOT_INSTALLED -DPRECOMPILED_SEARCH_MORE -m/home/nilsson/pike/dmalloc/master.pike Pike v8.1 release 9 running Hilfe v3.5 (Incremental Pike Frontend) Terminal closed. Strings left: 1 (65616 bytes) (zapped) 0x0x45d6ce0: 3 refs, len=0, size_shift=0, hval=0x (0) ""
==LEAK==: (0x45e9cb0) 2 bytes **Block: 0x45e9cb0 Type: PIKE_T_UNKNOWN Refs: -2088959992 **Cannot describe block of type PIKE_T_UNKNOWN (247) ******************* Locations that handled 0x45e9cb0: (gc generation: 0/6 gc pass: 0/0) *** /home/nilsson/pike/src/interpret_functions.h:3095 xalloc (1 times) !*! *** /home/nilsson/pike/src/pike_memory.c:356 malloc (1 times)
Not much help in the printout to pin it down.
There are some other errors nearby, but I think it is the lambdaopt branch merge the 23rd of November that is the culprit.
I just did the same bisect to verify, and found that the refcount miss was introduced in:
commit 4799ebf565c7c1ed84dd8fc0aa0d050ef9aee325 Author: Martin Nilsson nilsson@fastmail.com Date: Tue Jan 3 19:17:59 2017 +0100
String addition code from per/simplified-operators branch.
Which seems much more likely.
Right. I bisected for the
==LEAK==: (0x338dcb0) 2 bytes **Block: 0x338dcb0 Type: PIKE_T_UNKNOWN Refs: 1966669832 **Cannot describe block of type PIKE_T_UNKNOWN (247) ******************* Locations that handled 0x338dcb0: (gc generation: 0/6 gc pass: 0/0) *** /home/nilsson/pike/src/interpret_functions.h:3095 xalloc (1 times) !*! *** /home/nilsson/pike/src/pike_memory.c:356 malloc (1 times)
issue that remains. The string issue is fixed though.
pike-devel@lists.lysator.liu.se
-
el ＠ Pike developers forum -
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum
-
Martin Nilsson (Coppermist) ＠ Pike (-) developers forum