I've been having a problem with pike going into what seems like an infinite loop while exiting. The problem seems to occur with objects from my Objective-C module, and it's something I noticed before, but "solved" by adding a ref so that the objects were never freed. I fixed that problem last night, and now the problem is back.
The backtrace looks like this:
#0 schedule_really_free_object (o=0x1812038) at /Users/hww3/Pike/7.7/ src/object.c:1068 #1 0x00016610 in low_return () at /Users/hww3/Pike/7.7/src/ interpret.c:2018 #2 0x0001697c in jump_opcode_F_RETURN_0 () at /Users/hww3/Pike/7.7/ src/interpret_functions.h:1601 #3 0x007d5260 in ?? () #4 0x0001a76c in catching_eval_instruction (pc=0x1039114) at /Users/ hww3/Pike/7.7/src/interpret.c:2212 #5 0x0001a864 in jump_opcode_F_CATCH () at /Users/hww3/Pike/7.7/src/ interpret_functions.h:1273 #6 0x01039108 in ?? () #7 0x000181ac in mega_apply (type=25239608, args=2, arg1=0x13, arg2=0xffffffff) at /Users/hww3/Pike/7.7/src/interpret.c:2180 #8 0x00003644 in main (argc=2, argv=0xbffff974) at /Users/hww3/Pike/ 7.7/src/main.c:569
and if I step through the code, I eventually get back to the same point with the same object, and Pike never exits. Anyone with some internals experience care to venture a guess as to what the problem might be?
Bill
I've been having a problem with pike going into what seems like an infinite loop while exiting. The problem seems to occur with objects from my Objective-C module, and it's something I noticed before, but "solved" by adding a ref so that the objects were never freed. I fixed that problem last night, and now the problem is back.
The backtrace looks like this:
#0 schedule_really_free_object (o=0x1812038) at /Users/hww3/Pike/7.7/ src/object.c:1068
[...]
and if I step through the code, I eventually get back to the same point with the same object, and Pike never exits. Anyone with some internals experience care to venture a guess as to what the problem might be?
I guess that's me...
schedule_really_free_object() gets called when the object reference count reaches zero. If the object hasn't been destructed, it gets added to the objects_to_destruct queue. Otherwise the object is freed. An object can thus arrive at schedule_really_free_object() twice; once before destruct() and once after. If an object arrives at schedule_really_free_object() more times than that, it's a strong hint that there's a missing add_ref() somewhere.
Bill
I guess that's me...
schedule_really_free_object() gets called when the object reference count reaches zero. If the object hasn't been destructed, it gets added to the objects_to_destruct queue. Otherwise the object is freed. An object can thus arrive at schedule_really_free_object() twice; once before destruct() and once after. If an object arrives at schedule_really_free_object() more times than that, it's a strong hint that there's a missing add_ref() somewhere.
OK, that all makes sense to me, but if I've missed an add_ref() in my code, shouldn't that cause the object to be freed or destructed prematurely? I added an add_ref(o) to my code to prevent this problem, but the result was that the objects weren't getting freed. I've stepped through a simple program that exhibits the problem, and that object comes to schedule_really_free_object() numerous times, each time with a refcount of 0 or -1. I've noticed that once it finally enters its endless loop, o->next == o... shouldn't that cause the loop to stop?
Bill
pike-devel@lists.lysator.liu.se
-
H. William Welliver III -
H.William Welliver III
-
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum