threaded tcl "alloc: invalid block" errors
jul...@precisium.com.au
using mingw and with threads enabled (thread2.4) and while I've not
looked too deeply - I'm not having much luck so far.
From one of my apps I'm consistently getting:
-----------------------------------------
alloc: invalid block: 004152B8: 6c 0 63
abnormal program termination
-----------------------------------------
I've tried the 8.4.1 release, and also after applying the patch from
this issue:
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=597924&group_id=10894
(though the patch didn't apply fully - failed to patch 1 chunk in
tclWinSerial.c)
This patched version does seem to fix the bug it was meant to.. so
that's a step forward, but this invalid block error is 2 steps back for
me as now my app mentioned above won't run at all ;)
Tried to get a later version, but was unable to build the HEAD version
CVSed on 2002-12-20.
(tclwinsock.c error)
Also not been able to build the latest thread extension from CVS
(threadCmd.o error)
Unfortunately my app is probably being a bit messy and adventurous and
calling extensions that mightn't be thread-safe anyway (such as tclcurl)
so it's not the best candidate for narrowing down problems, but it did
work using my tcl8.4a1 build of tcl and thread2.4.
I saw a similar issue mentioned in this thread that suggested this issue
was intermittent and/or partly fixed - and I was wondering if I'm
hitting the same thing and/or whether anyone can point me to some more
info on what might be happening.
http://www.mail-archive.com/aols...@listserv.aol.com/msg03978.html
This invalid block crash also happens with the tcl build from:
http://members10.tsukaeru.net/bitwalk/download_mingw.html
If nobody has any fixes/further info at the moment, I'll see if I can
dig a little closer to what might be going on.
I've only just found that there's a threaded build for windows on
sourceforge - will check that out now.
Cheers,
Julian
jul...@precisium.com.au
> I've only just found that there's a threaded build for windows on
> sourceforge - will check that out now.
>
Tried tcl/Tk threads 8.4.1 found here:
http://sourceforge.net/project/showfiles.php?group_id=1616&release_id=120053
Same old abnormal program termination - also with the static version.
I guess it's time to proceed to the old "puts" statements, or maybe
even finally take the time to investigate some more serious debugging
methods.
Julian
Jeffrey Hobbs
>> I've only just found that there's a threaded build for windows on
>> sourceforge - will check that out now.
> Tried tcl/Tk threads 8.4.1 found here:
> http://sourceforge.net/project/showfiles.php?group_id=1616&release_id=120053
>
>
> Same old abnormal program termination - also with the static version.
What exactly are you doing? I've not seen this abort error before, and
have used threaded builds on Windows, even just recently. However, I
always build with VC++.
--
Jeff Hobbs The Tcl Guy
Senior Developer http://www.ActiveState.com/
Tcl Support and Productivity Solutions
jul...@precisium.com.au
>>
>> Same old abnormal program termination - also with the static version.
>
>
> What exactly are you doing? I've not seen this abort error before, and
> have used threaded builds on Windows, even just recently. However, I
> always build with VC++.
>
but oops, I see now my tclcurl is about 4 releases out of date.
0.9.3 whereas the most recent is 0.10.1
I'll update that and see how it goes.
Julian
David Gravereaux
>jul...@precisium.com.au wrote:
>>> I've only just found that there's a threaded build for windows on
>>> sourceforge - will check that out now.
>
>> Tried tcl/Tk threads 8.4.1 found here:
>> http://sourceforge.net/project/showfiles.php?group_id=1616&release_id=120053
>>
>>
>> Same old abnormal program termination - also with the static version.
>
>What exactly are you doing? I've not seen this abort error before, and
>have used threaded builds on Windows, even just recently. However, I
>always build with VC++.
It's from the thread allocator-> generic/tclThreadAlloc.c(748)
Try removing -DUSE_THREAD_ALLOC from the CFLAGS. I haven't seen this
error for my stuff, yet...
--
David Gravereaux <davy...@pobox.com>
[species: human; planet: earth,milkyway,alpha sector]
jul...@precisium.com.au
The following script run in a threaded tclsh crashes during the cleanup
call (my app was crashing during the configure call)
package require TclCurl
set ch [curl::init]
$ch configure -url http://telstra.com
$ch perform
$ch cleanup
Julian
Jeff Hobbs
"jul...@precisium.com.au" <jul...@precisium.com.au> wrote in
news:3E0366C8...@precisium.com.au:
>> Looks like it is crashing during HTTP fetches using tclcurl -
>> but oops, I see now my tclcurl is about 4 releases out of date.
>> 0.9.3 whereas the most recent is 0.10.1
> Updated to TclCurl 0.10.1
>
> The following script run in a threaded tclsh crashes during the cleanup
> call (my app was crashing during the configure call)
OK, more info now ... it appears to be an extension that is the problem.
Was the extension compiled with --enable-threads as well?
Does TclCurl have any statement about it being thread-safe?
Any lack of statement should be assumed to mean No.
What you are doing can be done with just the http core package, which
is thread-safe (being pure Tcl). Is there a reason not to use that?
Jeff
jul...@precisium.com.au
>>Updated to TclCurl 0.10.1
>>
>>The following script run in a threaded tclsh crashes during the cleanup
>>call (my app was crashing during the configure call)
>
>
> OK, more info now ... it appears to be an extension that is the problem.
> Was the extension compiled with --enable-threads as well?
> Does TclCurl have any statement about it being thread-safe?
> Any lack of statement should be assumed to mean No.
>
> What you are doing can be done with just the http core package, which
> is thread-safe (being pure Tcl). Is there a reason not to use that?
>
> Jeff
Yeah, sorry for not digging through to the real issue initially.
I admit to being a bit gung-ho about trying extensions with threaded tcl
and hoping they work. I guess the price you pay is that it's not so much
a case of they either do or don't work, but that they can appear to work
and then break unexpectedly and intermittently etc.
Anyway, for my purposes I think I can use the http core package instead
- I just liked the multiple protocols available in libcurl and it's (for
me) ease of use.
I was also lazy in that I just used a precompiled binary of tclcurl - so
no, I guess it wasn't even built with --enable-threads... suppose I
really was being a bit silly.
So - my apologies for wasting your time, and thanks for the comments
anyway.
Merry $whatever_people_celebrate
Julian
David Gravereaux
>Yeah, sorry for not digging through to the real issue initially.
>I admit to being a bit gung-ho about trying extensions with threaded tcl
>and hoping they work. I guess the price you pay is that it's not so much
>a case of they either do or don't work, but that they can appear to work
>and then break unexpectedly and intermittently etc.
I think what you did is good. We need to flush-out all the extensions now
that threads are coming into there own.
Andres Garcia
I have been looking into the problem, and I am afraid that
I don't yet know what happens.
Only thing I know so far, is that the extension crashes when
Tcl_Free is called to free the space used to store the string
with the URL.
Anyone knows what the reason may be? and where can I find some info
about how to make TclCurl thread safe? libcurl already is, so it
shouldn't be hard (I hope)
> So - my apologies for wasting your time, and thanks for the comments
> anyway.
You are certainly not wasting mine, if nobody tells me about the problems
they have with TclCurl I can hardly fix them. But Jeff is right, if the
http package does everything you need there is no point in using TclCurl.
Merry Christmas,
Andres
Andres Garcia
> Only thing I know so far, is that the extension crashes when
> Tcl_Free is called to free the space used to store the string
> with the URL.
Answering myself, the problem seems to be that I created the
strings using strdup, so freeing them with Tcl_Free wasn't
a good idea. At least, now that I have reimplemented strdup
using Tcl_Alloc, the tests seems to run in a threaded tclsh
in Linux.
I don't yet know when I am going to release a new TclCurl version,
if someone wants a prerelease, please let me know.
Andres
David Gravereaux
>Hi,
>
>I have been looking into the problem, and I am afraid that
>I don't yet know what happens.
>
>Only thing I know so far, is that the extension crashes when
>Tcl_Free is called to free the space used to store the string
>with the URL.
>
>Anyone knows what the reason may be? and where can I find some info
>about how to make TclCurl thread safe? libcurl already is, so it
>shouldn't be hard (I hope)
Probably the Tcl_Free() wasn't called from the same thread that the
Tcl_Alloc() that created the buffer was called from. But given the small
script, it doesn't look like anything is getting passed around. Does
libcurl use threads on the inside?
package require TclCurl
set ch [curl::init]
$ch configure -url http://telstra.com
$ch perform
$ch cleanup
>> So - my apologies for wasting your time, and thanks for the comments
>> anyway.
>
>You are certainly not wasting mine, if nobody tells me about the problems
>they have with TclCurl I can hardly fix them. But Jeff is right, if the
>http package does everything you need there is no point in using TclCurl.
>
>Merry Christmas,
>
>Andres
>
--