X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-1.9 required=5.0	tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,T_TO_NO_BRKTS_FREEMAIL
X-Spam-Check-By: sourceware.org
MIME-Version: 1.0
In-Reply-To: <20110208115915.GK24247@calimero.vinschen.de>
References: <AANLkTinS8oPJqwsoYkCkkuYvFY5rQTKgiP4nJEhEA0J6 AT mail DOT gmail DOT com>	<20110208115915 DOT GK24247 AT calimero DOT vinschen DOT de>
Date: Tue, 8 Feb 2011 13:14:46 +0100
Message-ID: <AANLkTi=1Com2uXWddcUnF32g5bnJRB6Rzc1HBQGFMG5z@mail.gmail.com>
Subject: Re: TP_NUM_C_BUFS too small
From: marco atzeri <marco DOT atzeri AT gmail DOT com>
To: cygwin AT cygwin DOT com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On Tue, Feb 8, 2011 at 12:59 PM, Corinna Vinschen  wrote:
> On Feb =A07 22:38, marco atzeri wrote:
>> I am testing latest release candidate for octave, and only on cygwin usi=
ng
>> 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. =A0There's a thread-local
> storage in the highest area of the thread local stack. =A0In 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. =A0That counter has the value 79987540, which
> looks *very* wrong.

I was sure .

>
>> Stack trace:
>> Frame =A0 =A0 Function =A0Args
>> 0022CF90 =A06102773B =A0(0022CF90, 00000000, 00000000, 00000000)
>> 0022D280 =A06102773B =A0(6117CC60, 00008000, 00000000, 6117E997)
>> 0022E2B0 =A061004E5B =A0(611C978C, 04C48354, 0000000A, 0022E4E4)
>> 0022E2D0 =A0610EF554 =A0(0022F578, 00000001, 00000000, 00000000)
>> 0022F5A0 =A061096D4F =A0(61208220, 0002625A, 00001000, 000BF399)
>> 011AE3F4 =A0610225C2 =A0(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. =A0The problem is that the stackdump is not very helpful
> to find the cause. =A0The 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 outp=
ut
>> (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. =A0If 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. =A0From
> there it's detective work. =A0Maybe 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