This is the mail archive of the
mailing list for the Cygwin project.
Re: TP_NUM_C_BUFS too small
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
> 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
> 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 Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple