From: SourceForge.net <no...@so...> - 2008-07-21 07:40:01
|
Bugs item #1909647, was opened at 2008-03-07 16:47 Message generated for change (Comment added) made by ctasada You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1909647&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 69. Other Group: obsolete: 8.5.1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Carlos Tasada (ctasada) Assigned to: miguel sofer (msofer) Summary: TclStackFree: incorrect freePtr. Call out of sequence? Initial Comment: Hi guys, We're using ActiveTcl 8.5.1, bytecoded with tbcload1.7. From time to time, the application crashes with a "TclStackFree: incorrect freePtr. Call out of sequence?", but so far this happens only in Linux. We're using threads and sockets actively and usually the crash appears just after a "puts" in a file or after a socket is closed. I don't even known how to start debugging the problem. I've been looking into Tcl sourcecode and the first think that I see regarding the use of TclStackFree is that it's used in the Linux version of TclpCreateProcess, but not in Windows. Following this lead I finished in the Tcl_OpenCommandChannel, the one used to process the tcl exec command. Am I in drunks o could be that some error or wrongly synched command in the Tcl_OpenCommandChannel could be producing this problem? Any help is more than welcome. Cheers, Carlos ---------------------------------------------------------------------- >Comment By: Carlos Tasada (ctasada) Date: 2008-07-21 09:40 Message: Logged In: YES user_id=340696 Originator: YES Hi Miguel, I'll do my best to send you more info this week. Best Regards, Carlos. ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2008-07-21 06:49 Message: Logged In: YES user_id=148712 Originator: NO Sorry this flew under my radar. More info: ideally a smallish example to repro. But at least (a) assurance that the threading model is respected: each interp is only called from the thread where it was created (b) a stack trace ---------------------------------------------------------------------- Comment By: Carlos Tasada (ctasada) Date: 2008-06-30 10:17 Message: Logged In: YES user_id=340696 Originator: YES Hi Miguel, What more info do you need? My main problem is that I cannot replicate the problem in an easy way. But I found some extra info about that. We've the same code running in 32 and 64 bits and seems that the problem happens more frequently in 64b. Anyway just ask me what more info do you need and I'll do anything on my side to send it to you. ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2008-06-28 15:43 Message: Logged In: YES user_id=148712 Originator: NO Submitter went AWOL? I'm still suspecting a violation of Tcl's threading model. In order to do anything about this I would need more info. ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2008-03-11 14:30 Message: Logged In: YES user_id=148712 Originator: NO On the timing issue: TclStackAlloc/TclStackFree is a very specialised internal allocator, it reserves memory in Tcl's internal stack. It is of the utmost importance for its proper functioning that frees occur in the precise reverse sequence of allocs (*), or else get a panic. What you are seeing is a violation of this timing principle. Had this happened in a single thread, the crash would be deterministic - an obvious bug with a slim chance of making it past the testing phase. However, if different threads are allocing/freeing from the same interp's stack (shouldn't happen as the stack is interp-specific), thread coordination issues could cause the observed behaviour. This is what I suspect. Not much of a clue beyond that yet. (*) They should also be precisely coordinated with the bytecode engine's own usage of the stack. This is an internal allocator that is not meant to be used by extensions. ---------------------------------------------------------------------- Comment By: Carlos Tasada (ctasada) Date: 2008-03-11 14:14 Message: Logged In: YES user_id=340696 Originator: YES Hi Miguel, What do you mean by "wrong timing"? Some "after"? or maybe some async thread that's released too early? Can the problem be related with some "exec" command as I said before? Regarding you questions 1) I already though about that. I doing some changes in the sourcecode and I have a client that volunteer to test it running from source. Hope I'll have something new in a couple of days. 2) I'm using threads from scripts. 3) That's the bad part. I'm trying to find how to simplify the problem as much as possible to have a nice test case. Anyway seems that's related with some other problem that's leaking memory (I'm looking into that right now). At the moment that I "puts" to a file, seems that the used memory is too much and the application crashes. Best Regards, Carlos Tasada. ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2008-03-11 13:48 Message: Logged In: YES user_id=148712 Originator: NO This definitely looks like a threading problem: wrong timing within the same thread will cause TclStackFree to bomb reliably. First let us try to reduce the problem a bit: (1) tbcload should have nothing to do with this; can you confirm by using the script sources instead of the precompiled version? I do not know if you have them available or not, it might be 3rd party code (2) You are using threads: script or C api? If C: are you respecting Tcl's threading model, "no calls to an interp from a different thread"? (3) Can you reduce the problem to some smallish demo that we can study? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1909647&group_id=10894 |