X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Date: Tue, 8 Feb 2011 12:59:15 +0100 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: TP_NUM_C_BUFS too small Message-ID: <20110208115915.GK24247@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , 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 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