TCSH problem (was ...)

[vefatica]

I reported a problem with TCSH:

But if I issue "d:/tcmd9/tcc.exe" (TCC starts in the console), when I
exit TCC, TCSH "encounters a problem" (message box appears) and TCMD gives the message

free(0x7fbdad88) bad block. (memtop = 0x7fc10800 membot = 0x7fbb0000)

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
​

I have tracked this down to the "UpdateTitle" directive.

The problem occurs with "UpdateTitle = No" and does not occur with "UpdateTitle = Yes".

Recall that the problem occurs when TCSH executes its precmd alias (title "$cwd") after the started 4NT process exits.

A wild guess is that something happens to the state of kernel32.dll (closing a handle that shouldn't be closed?).

I appreciate your point, Rex, that 4NT shouldn't even be able to influence what happens after it exits. I suppose TCSH's author might say something similar. Nevertheless there's a rather peculiar dependency on 4NT and the UpdateTitle directive in particular at play here.

 

[rconn]

vefatica wrote:

> I reported a problem with TCSH:
>
> But if I issue "d:/tcmd9/tcc.exe" (TCC starts in the console), when I
> exit TCC, TCSH "encounters a problem" (message box appears) and TCMD
> gives the message
>
> free(0x7fbdad88) bad block. (memtop = 0x7fc10800 membot = 0x7fbb0000)
>
> This application has requested the Runtime to terminate it in an
> unusual way.
> Please contact the application's support team for more information.
>
> I have tracked this down to the "UpdateTitle" directive.
>
> The problem occurs with "UpdateTitle = No" and does not occur with
> "UpdateTitle = Yes".

If "UpdateTitle=No", then TCC doesn't do *anything*. If it's set to
"Yes", then TCC updates the title (with SetConsoleTitle) and possibly
the icon (with SetConsoleIcon) at startup and after executing external apps.

> Recall that the problem occurs when TCSH executes its precmd alias
> (title "$cwd") after the started 4NT process exits.
>
> A wild guess is that something happens to the state of kernel32.dll
> (closing a handle that shouldn't be closed?).

That's a pretty wild guess, as it would require that both Intel (in the
hardware) and Microsoft (in Windows) made major blunders and are
allowing code to cross process boundaries and mangle other processes.
The state of kernel32.dll is unique to each process that links to it; it
is not shared across processes.

> I appreciate your point, Rex, that 4NT shouldn't even be able to
> influence what happens after it exits. I suppose TCSH's author might say
> something similar. Nevertheless there's a rather peculiar dependency on
> 4NT and the UpdateTitle directive in particular at play here.

But TCSH's author wouldn't have any justification in saying that! :-)

The real problem here seems to be that TCSH (by their own admission)
doesn't work correctly with apps compiled with MSVC. (Which would seem
to be a problem with something intended to be used with Windows!)

Rex Conn
JP Software

 

[vefatica]

On Sun, 26 Oct 2008 22:24:45 -0500, "JP Software Forums" <[email protected]>,rconn
<> wrote:

>vefatica wrote:
>
>
>---Quote---
>> I reported a problem with TCSH:
>>
>> But if I issue "d:/tcmd9/tcc.exe" (TCC starts in the console), when I
>> exit TCC, TCSH "encounters a problem" (message box appears) and TCMD
>> gives the message
>>
>> free(0x7fbdad88) bad block. (memtop = 0x7fc10800 membot = 0x7fbb0000)
>>
>> This application has requested the Runtime to terminate it in an
>> unusual way.
>> Please contact the application's support team for more information.
>>
>> I have tracked this down to the "UpdateTitle" directive.
>>
>> The problem occurs with "UpdateTitle = No" and does not occur with
>> "UpdateTitle = Yes".
>---End Quote---
>If "UpdateTitle=No", then TCC doesn't do *anything*. If it's set to
>"Yes", then TCC updates the title (with SetConsoleTitle) and possibly
>the icon (with SetConsoleIcon) at startup and after executing external apps.

That's exactly what I figured. I'm surprised it isn't the other way around
(error with UpdateTitle=Yes). Nevertheless, either test is utterly
reproducible. It makes me very curious.

>---Quote---
>> Recall that the problem occurs when TCSH executes its precmd alias
>> (title "$cwd") after the started 4NT process exits.
>>
>> A wild guess is that something happens to the state of kernel32.dll
>> (closing a handle that shouldn't be closed?).
>---End Quote---
>That's a pretty wild guess, as it would require that both Intel (in the
>hardware) and Microsoft (in Windows) made major blunders and are
>allowing code to cross process boundaries and mangle other processes.
>The state of kernel32.dll is unique to each process that links to it; it
>is not shared across processes.

Yeah, that was wild. But **something** is having an effect across process
boundaries.

>---Quote---
>> I appreciate your point, Rex, that 4NT shouldn't even be able to
>> influence what happens after it exits. I suppose TCSH's author might say
>> something similar. Nevertheless there's a rather peculiar dependency on
>> 4NT and the UpdateTitle directive in particular at play here.
>---End Quote---
>But TCSH's author wouldn't have any justification in saying that! :-)
>
>The real problem here seems to be that TCSH (by their own admission)
>doesn't work correctly with apps compiled with MSVC. (Which would seem
>to be a problem with something intended to be used with Windows!)

I've not seen such an admission. Where is it? Are we talking about the same
TCSH originally ported by Amol Deshpande (I don't know who's doing it now) ...

version tcsh 6.15.00 (Astron) 2007-03-03 (i386-Microsoft-WindowsNT) options 8b,
dl,kan,hb,color,dspm,nt-rev-8.08

 

[rconn]

vefatica wrote:

> Quote:
> >---Quote---
> >> I appreciate your point, Rex, that 4NT shouldn't even be able to
> >> influence what happens after it exits. I suppose TCSH's author might
> say
> >> something similar. Nevertheless there's a rather peculiar dependency on
> >> 4NT and the UpdateTitle directive in particular at play here.
> >---End Quote---
> >But TCSH's author wouldn't have any justification in saying that! :-)
> >
> >The real problem here seems to be that TCSH (by their own admission)
> >doesn't work correctly with apps compiled with MSVC. (Which would seem
> >to be a problem with something intended to be used with Windows!)
>
> I've not seen such an admission. Where is it? Are we talking about the same
> TCSH originally ported by Amol Deshpande (I don't know who's doing it
> now) ...

In a previous message, you said there was a bug report in the TCSH list
regarding MSVC apps, including a hotfix (which didn't work). So
presumably you already know where it is!

Rex Conn
JP Software

 

[vefatica]

On Mon, 27 Oct 2008 07:12:23 -0500, "JP Software Forums" <[email protected]>,rconn
<> wrote:

>In a previous message, you said there was a bug report in the TCSH list
>regarding MSVC apps, including a hotfix (which didn't work). So
>presumably you already know where it is!

I found http://support.microsoft.com/kb/884538 on my own; it has nothing
specifically to do with TCSH.

 

[vefatica]

In a previous message, you said there was a bug report in the TCSH list
regarding MSVC apps, including a hotfix (which didn't work). So
presumably you already know where it is!

I responded to the above by email at 9:51 ... received my post by email at 10:02. Now it's 10:16 and it still does not appear on the web forum.

I said:

I found http://support.microsoft.com/kb/884538 on my own; it has nothing
specifically to do with TCSH.

 

[vefatica]

Reproduce the problem much more simply.

Start 4NT/TCC (with UpdateTitle-No).

Issue: [path\]tcsh.exe (with alias precmd 'title "$cwd"')

Crash!

Console says:

title: No match.
free(0x7fbc5188) bad block. (memtop = 0x7fbc6800 membot = 0x7fbb0000)

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

Also MessageBox says "tcsh has encountered ...".

 

[vefatica]

Even easier that that! I posted the following update to my report in the TCSH forum:

It's much easier to cause the crash. And this method does not depend on 4NT's "UpdateTitle" directive or on TCSH's "precmd" alias.

In a running 4NT, simply start TCSH. It crashed immediately, as described earlier. In the console:

title: No match.
free(0x7fbbaa88) bad block. (memtop = 0x7fbc6800 membot = 0x7fbb0000)

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

And also a message box: "tcsh.exe has encountered a problem and needs to close"

Rex, I'm not saying 4NT does anything wrong but I cannot find another scenario in which TCMD fails to start.

 

[vefatica]

Sorry! Reproducing the crash as described below **does** require "UpdateTitle-No".

Even easier that that! I posted the following update to my report in the TCSH forum:

It's much easier to cause the crash. And this method does not depend on 4NT's "UpdateTitle" directive or on TCSH's "precmd" alias.

In a running 4NT, simply start TCSH. It crashed immediately, as described earlier. In the console:

title: No match.
free(0x7fbbaa88) bad block. (memtop = 0x7fbc6800 membot = 0x7fbb0000)

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

And also a message box: "tcsh.exe has encountered a problem and needs to close"

Rex, I'm not saying 4NT does anything wrong but I cannot find another scenario in which TCMD fails to start.