Re: snit, and bug tracker

[Bernard D. <bde...@or...>]

Hi Lars,

I have fixed this bug. This was caused, as I suspected, by a missing closeProc in the Tcl_ChannelType struct of our console. It was set to NULL which it shouldn't. This part of the code has been in place for decades (I’m not the author!) and it is amazing that we didn’t hit this bug before.
Here is what I get now instead of a crash:
Welcome to AlphaX's AlphaTcl shell.
«Development» mtime [now]
20/05/15 10:58:05
«Development» chan names
stdout stdin stderr serial1 sock7082090 serial2
«Development» close stdout
«Development» chan names
stdin stderr serial1 sock7082090 serial2
«Development» puts stdout foobar
Error: can not find channel named "stdout"

I hope this fixes the issue with snit.

I plan to release an update of AlphaX (8.2.3) as soon as possible.

Cheers,
Bernard

Le 18 mai 2015 à 12:55, Lars Hellström <Lar...@re...> a écrit :

> Bernard Desgraupes skrev 2015-05-16 06.59:
>> Hi Lars,
>> 
>> I can reproduce the crash. I’ll look into with the debugger.
> 
> I did some more debugging during the weekend. It turns out the following is 
> a minimal reproduction script:
> 
> interp create foo
> foo eval {close stdout}
> 
> (Snit does that because it uses a child interpreter for "compiling" stuff, 
> and initialisation of that starts with closing the standard channels in the 
> child. It only happens during validate.tcl because that is the first point 
> where snit creates any object.)
> 
> The reason this doesn't work in Alpha is probably that our stdout and stderr 
> are homecooked virtual channels; attempting to close them is what provokes 
> the crash.
> 
> I suspect one bug here is that some reference count is not initialised 
> properly, because the following does not crash Alpha:
> 
> interp create bar
> interp create foo
> foo eval {close stdout}
> 
> In Tcl, closing a channel in one interpreter will not close it in other 
> interpreters, so all that the [foo eval {close stdout}] should accomplish is 
> unregistering stdout from the foo interpreter, leaving it open in the main 
> interpreter. But if Alpha's stdout usually has a refcount of 0 then the 
> following will happen:
> 
> interp create foo
> # foo inherits stdin, stdout, and stderr from {}.
> # New stdout refcount is 1.
> foo eval {close stdout}
> # stdout refcount decremented, new value 0. Triggers Close().
> # CRASH
> 
> Since the crashdump says the crash happens in Close(), there might also be 
> some further error in how we've implemented stdout (I recall Bernard being 
> unhappy about how that is done), but losing stdout should in itself lead to 
> future problems, so it's worth fixing the refcount even if it wouldn't be a 
> complete bugfix.
> 
> With Tcl 8.6, we have pure-Tcl reflected channels, so possibly that could be 
> used instead of a homecooked solution. But I think we'd still have to do 
> something in C to make one of these the stdout.
> 
>> Concerning the bug reports, we had indeed a bugs tracker based on the Trac system, which replaced the old Bugzilla tracker. Both Bugzilla and Trac where external tools installed in the shell area of the project at SourceForge.  I don’t remember exactly why we had to switch from Bugzilla to Trac,
> 
> IIRC, Bugzilla ran on a machine in Australia, and migration was forced 
> because Daniel had lost his association with the owner of that machine.
> 
>> but probably, as you say, after an upgrade at SF which prevented the use of some database tool. Trac was anyway a more elegant and integrated tool, despite some irritating limitations. Then, Trac was removed from the external tools and services offered by SF : this happened they decided to switch completely to their Allura platform.
>> 
>> I must probably have somewhere a snapshot of the Trac database when it was definitely closed. I’ll see if I can find it and put some kind of archive on line.
>> 
>> I have just enabled the Tickets tracker provided by the Allura platform at SourceForge for future bug reports. Here is the URL:
>> https://sourceforge.net/p/alphatcl/tickets/
> 
> That's good. I'm not sure if I'll file this, but once one starts hacking, 
> there'll probably be some other things one encounters too.
> 
> Lars Hellström
> 
> 
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud 
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> AlphaTcl-developers mailing list
> Alp...@li...
> http://lists.sourceforge.net/lists/listinfo/alphatcl-developers