Re: [tcljava-user] debugging "assertion`tsdPtr->initialized' failed"

[Russell R. <rus...@gm...>]

Mo,

Thanks for taking the time to respond.

I'd already taken the step of turning on the TCLBLEND_DEBUG.
 Unfortunately, the last debug output prior to the crash provided no new
information - just that JavaCmdProc had been called.

I will poke around a bit more in the open source Jetty HttpClient code to
see if I can discern anything there.   Yes, there is a new thread kicked
off in there.   I'd gone so far as to put some println's in that code to
see if I could narrow the focus.   That seems to indicate we're making it
all the way through the HttpClient start method in the main thread and
crash upon return into tclblend...but i may be misinterpreting (i don't
pretend to know what i'm doing when it comes to the threaded world.)   The
most solid info I got was running it in gdb which showed the underlying
cause of the failed tclblend assert as sigsev while switching threads.

One other clue:   I'm running the exact same script in jtclsh and jaclsh.
 What is it telling us that this crash occurs in jtclsh instance but runs
cleanly in jaclsh?

Any hope that the problem might just 'go away' were I to find a way to do
my tclblend in tcl8.5 (where the thread implementation is part of the tcl
core) as opposed to the current external thread pkg?

Russell

On Fri, Feb 17, 2012 at 2:09 PM, Mo DeJong <mo...@mo...> wrote:

> Hi Russell
>
> So, this has something to do with threads. The specific assert you are
> running into is in JavaGetCache()
>
>
> http://tcljava.cvs.sourceforge.net/viewvc/tcljava/tcljava/src/native/javaCmd.c?revision=1.27&view=markup
>
> See line 398:
>
>
> 393     TCLBLEND_EXTERN JavaInfo*
> 394     JavaGetCache()
> 395     {
> 396     ThreadSpecificData *tsdPtr = TCL_TSD_INIT(&dataKey);
> 397
> 398     assert(tsdPtr->initialized);
> 399
> 400     return &(tsdPtr->jcache);
> 401     }
>
>
> So, this assert is being hit because the Java code calls into Tcl Blend
> and then Tcl Blend checks to see if the thread specific data has been
> initialized in this thread. That assert is failing for unknown reasons.
>
> My first thought would be to check to see if the Java code in your
> HttpClient is actually creating another background thread and then invoking
> Tcl Blend methods in that other background thread. That would be the most
> likely cause of the assert. It is quite honestly hard to track down Tcl
> Blend problems in gdb, it is possible, but not easy because Java calls into
> C and vice versa. It is possible to set breakpoints in the Tcl Blend C
> code, but it takes some gdb mojo.
>
> You can also enable the TCLBLEND_DEBUG macro and create a build that will
> print debug and init messages as it is loaded. This is a lot easier way to
> debug these issues compared to using gdb.
>
> As far as the class loading issue goes, it does seem very odd. What I
> would do is try to "exec javap CLASS" and see if you can invoke the JVM
> with the specific classpath you are using. If you can't get the JDK tools
> to read from that classpath, then that is the source of your problem. Also,
> make sure the classpath being used in Jacl is exactly the same as the one
> being used in Tcl Blend (aside from jacl.jar vs tclblend.jar).
>
> Mo
>
> On Feb 16, 2012, at 12:20 PM, Russell Roy wrote:
>
> > I have a simple script.  It works w/o error in jaclsh.  It core dumps in
> jtclsh.
> >
> > Here's the script:
> >
> > 1 set env(TCL_CLASSPATH) "...some-big-long-classpath..."
> > 2 package require java
> > 3 set httpClient [java::new org.eclipse.jetty.client.HttpClient]
> > 4 $httpClient start
> >
> > The script crashes in jtclsh on line 4 with this message:
> >
> >        tclsh8.4: /home/rroy/tcljava/src/native/javaCmd.c:398:
> JavaGetCache: Assertion `tsdPtr->initialized' failed.
> > Aborted (core dumped)
> >
> > That's the whole of the output when the thing dies.
> >
> >
> > I was hoping to be able to do some java debugging by running the script
> in jaclsh but, as I said, the thing works fine there - no problem, no
> crash.   I really need this to work in jctlsh.
> >
> >
> > I'm using tclBlend 1.4.1 pulled from latest at sourceforge, and
> thread2.6.5, tcl 8.4.19  (I also tried various permutations and
> combinations of thread2.6.3, tcl8.4.13 and earlier versions of tclBlend,
> all w/o any luck.)
> >
> > I've rebuilt and and re-installed tclBlend cleanly with each change so
> as to ensure consistency and jaclsh and jtclsh are setting up a correct
> environment but the problem persists.
> >
> > I stuck the core image in gdb but I there's was nothing discernibly
> useful, to me anyways (I believe the failed assertion is forcing the core
> dump.)
> >
> >
> > I've run out of ideas on how to debug this.
> >
> >
> > Russ
> >
> > PS:   For what it's worth ... The HttpClient of above comes in two
> flavors - CONNECTOR_SOCKET and CONNECTOR_SELECT_CHANNEL (the default).   I
> happened to discover through trial and error that if I configure the client
> as CONNECTOR_SOCKET before I do the start then it runs w/o error in jtclsh.
>   That's interesting but it doesn't help me because I need to run in it as
> select channel.
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Virtualization & Cloud Management Using Capacity Planning
> > Cloud computing makes use of virtualization - but cloud computing
> > also focuses on allowing computing to be delivered as a service.
> >
> http://www.accelacomm.com/jaw/sfnl/114/51521223/_______________________________________________
> > tcljava-user mailing list
> > tcl...@li...
> > https://lists.sourceforge.net/lists/listinfo/tcljava-user
>
>