From: marco atzeri <marco.atzeri@gmail.com>
To: cygwin@cygwin.com
Subject: Re: TP_NUM_C_BUFS too small
Date: Tue, 08 Feb 2011 12:14:00 -0000 [thread overview]
Message-ID: <AANLkTi=1Com2uXWddcUnF32g5bnJRB6Rzc1HBQGFMG5z@mail.gmail.com> (raw)
In-Reply-To: <20110208115915.GK24247@calimero.vinschen.de>
On Tue, Feb 8, 2011 at 12:59 PM, Corinna Vinschen wrote:
> 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.
I was sure .
>
>> 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?
any 1.7.x or snapshots that I tested in the last 6 months, since fltk
1.1.10-1 was available.
This crash always happens, and it seems a specific cygwin only issue.
>> 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.
thanks for looking
>
>> 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.
Time to learn serious gdb debugging.
>
>
> Corinna
>
thanks
Marco
--
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
next prev parent reply other threads:[~2011-02-08 12:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-07 21:38 marco atzeri
2011-02-08 11:59 ` Corinna Vinschen
2011-02-08 12:14 ` marco atzeri [this message]
2011-02-08 12:25 ` Corinna Vinschen
2015-11-01 17:46 Helmut Karlowski
2015-11-01 19:35 ` Helmut Karlowski
2015-11-02 2:32 ` Mark Geisert
2015-11-02 11:15 ` Corinna Vinschen
2015-11-02 23:07 ` Helmut Karlowski
2015-11-03 13:02 ` Corinna Vinschen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='AANLkTi=1Com2uXWddcUnF32g5bnJRB6Rzc1HBQGFMG5z@mail.gmail.com' \
--to=marco.atzeri@gmail.com \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).