Re: TP_NUM_C_BUFS too small

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

On Feb  7 22:38, marco atzeri wrote:
> I am testing latest release candidate for octave, and only on cygwin using
> the fltk graphics interface when we try to print through ghostscript we have:
> 
> octave 4236 E:\cygwin2\bin\octave-3.3.92.exe: *** fatal error -
> Internal error: TP_NUM_C_BUFS too small: 79987540 > 10

This message points to a stack corruption.  There's a thread-local
storage in the highest area of the thread local stack.  In this TLS area
are a couple of buffer pointers which point to mallocated storage.
There are up to 10 of the "C_BUF" pointers and a counter which contains
the number of used pointers.  That counter has the value 79987540, which
looks *very* wrong.

> Stack trace:
> Frame     Function  Args
> 0022CF90  6102773B  (0022CF90, 00000000, 00000000, 00000000)
> 0022D280  6102773B  (6117CC60, 00008000, 00000000, 6117E997)
> 0022E2B0  61004E5B  (611C978C, 04C48354, 0000000A, 0022E4E4)
> 0022E2D0  610EF554  (0022F578, 00000001, 00000000, 00000000)
> 0022F5A0  61096D4F  (61208220, 0002625A, 00001000, 000BF399)
> 011AE3F4  610225C2  (6F2F6572, 76617463, 2E332F65, 32392E33)
> End of stack trace
> Hangup
> 
> This is on latest cygwin snapshot, but it crash on any version release.

So this occurs on 1.7.7 as well?

> I suspect the error message is a red herring. Am I right ?

Yes, it is.  The problem is that the stackdump is not very helpful
to find the cause.  The information you can gather is where the problem
is encountered, but it doesn't show what overwrote the TLS area.

> The plot is built as expected, so gs is doing its work; from strace output
> (available on http://matzeri.altervista.org/works/octave/)

There's nothing in octave_fltk.strace which points to any kind of
problem.

> I guess that gs execution is unable to return back on octave.
> 
> Suggestion for debugging ?

Build the Cygwin DLL for debugging (just -g, no -O2), build octave for
debugging, and try to find the problem.

What I can see from the stack dump is that it happens when trying to
open a file.  If you find the Cygwin call (probably, but not necessarily
open()) from octave in which the problem is encountered, you can narrow
down the problem to somewhere between this call and the previous
file-related call since all of these calls access the TLS buffers.  From
there it's detective work.  Maybe a watchpoint on the aforementioned
counter helps (class tls_pathbuf, member c_cnt).

This is pretty tricky to find, I fear.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple