TP_NUM_C_BUFS too small

TP_NUM_C_BUFS too small

[Helmut Karlowski]

Hello

just had a program crashing with this error:

  2 [main] ue 3180 C:\bin\ue.exe: *** fatal error - Internal error:  
TP_NUM_C_BUFS too small: 50

What could that mean?

#uname -srvmo
CYGWIN_NT-10.0-WOW 2.2.1(0.289/5/3) 2015-08-20 11:40 i686 Cygwin

-Helmut


--

--
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

Re: TP_NUM_C_BUFS too small

[Helmut Karlowski]

Am 01.11.2015, 18:46 Uhr, schrieb Helmut Karlowski:

>
> Hello
>
> just had a program crashing with this error:
>
>   2 [main] ue 3180 C:\bin\ue.exe: *** fatal error - Internal error:  
> TP_NUM_C_BUFS too small: 50
>
> What could that mean?

It means my program had a bug - fixed now.

-Helmut

--
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

Re: TP_NUM_C_BUFS too small

[Mark Geisert]

Helmut Karlowski writes:
> Am 01.11.2015, 18:46 Uhr, schrieb Helmut Karlowski:
> > Hello
> >
> > just had a program crashing with this error:
> >
> >   2 [main] ue 3180 C:\bin\ue.exe: *** fatal error - Internal error:  
> > TP_NUM_C_BUFS too small: 50
> >
> > What could that mean?
> 
> It means my program had a bug - fixed now.

Glad it's fixed!  For the record, could you say what sort of bug would cause
a fatal internal error like that?
Just curious,

..mark


--
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

Re: TP_NUM_C_BUFS too small

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 753 bytes --]

On Nov  2 02:32, Mark Geisert wrote:
> Helmut Karlowski writes:
> > Am 01.11.2015, 18:46 Uhr, schrieb Helmut Karlowski:
> > > Hello
> > >
> > > just had a program crashing with this error:
> > >
> > >   2 [main] ue 3180 C:\bin\ue.exe: *** fatal error - Internal error:  
> > > TP_NUM_C_BUFS too small: 50
> > >
> > > What could that mean?
> > 
> > It means my program had a bug - fixed now.
> 
> Glad it's fixed!  For the record, could you say what sort of bug would cause
> a fatal internal error like that?
> Just curious,

Me too.  Sounds like some kind of recursion.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: TP_NUM_C_BUFS too small

[Helmut Karlowski]

Am 02.11.2015, 12:15 Uhr, schrieb Corinna Vinschen:

>> Glad it's fixed!  For the record, could you say what sort of bug would  
>> cause
>> a fatal internal error like that?
>> Just curious,
>
> Me too.  Sounds like some kind of recursion.

It all happened after I had replaced all strcpy/strcat by strlcpy like  
this:

strcpy(t,s) -> pos = strlcpy(t,s,size)
strcat(t,s) -> pos += strlcpy(t+pos,s,size-pos)

At some point the pos-parameter was wrong and the resulting string became  
something undesired. And that string probably was passed to fopen, maybe  
pos became very large way beyond the boundaries of the string which is  
 from the stack.

It's hard to reproduce what happened in a simple case, and I was in some  
hurry then, but I saved the strace-output:

   459 4265672 [main] ue 460 open: open(u, 0x0)
    33 4265705 [main] ue 460 normalize_posix_path: src u
    33 4265738 [main] ue 460 cwdstuff::get: posix /usr/src/ue314/bin
    32 4265770 [main] ue 460 cwdstuff::get: (/usr/src/ue314/bin) =  
cwdstuff::get (0x80000008, 32768, 1, 0), errno 2
    33 4265803 [main] ue 460 normalize_posix_path: /usr/src/ue314/bin/u =  
normalize_posix_path (u)
    33 4265836 [main] ue 460 mount_info::conv_to_win32_path:  
conv_to_win32_path (/usr/src/ue314/bin/u)
    33 4265869 [main] ue 460 set_flags: flags: binary (0x2)
    33 4265902 [main] ue 460 mount_info::conv_to_win32_path: src_path  
/usr/src/ue314/bin/u, dst C:\cygwin\usr\src\ue314\bin\u, flags 0x3000A, rc  
0
    63 4265965 [main] ue 460 symlink_info::check: 0x0 = NtCreateFile  
(\??\C:\cygwin\usr\src\ue314\bin\u)
    49 4266014 [main] ue 460 symlink_info::check: not a symlink
    47 4266061 [main] ue 460 symlink_info::check: 0 =  
symlink.check(C:\cygwin\usr\src\ue314\bin\u, 0x29B598) (0x3000A)
    35 4266096 [main] ue 460 path_conv::check:  
this->path(C:\cygwin\usr\src\ue314\bin\u), has_acls(1)
    37 4266133 [main] ue 460 build_fh_pc: fh 0x61302754, dev 000000C3
    34 4266167 [main] ue 460 fhandler_base::open:  
(\??\C:\cygwin\usr\src\ue314\bin\u, 0x108000)
    70 4266237 [main] ue 460 fhandler_base::set_flags: flags 0x108000,  
supplied_bin 0x10000
    34 4266271 [main] ue 460 fhandler_base::set_flags: filemode set to  
binary
    33 4266304 [main] ue 460 fhandler_base::open: 0x0 = NtCreateFile  
(0x170, 0x80100000, \??\C:\cygwin\usr\src\ue314\bin\u, io, NULL, 0x0, 0x7,  
0x1, 0x4020, NULL, 0)
    35 4266339 [main] ue 460 fhandler_base::open: 1 =  
fhandler_base::open(\??\C:\cygwin\usr\src\ue314\bin\u, 0x108000)
    41 4266380 [main] ue 460 fhandler_base::open_fs: 1 =  
fhandler_disk_file::open(\??\C:\cygwin\usr\src\ue314\bin\u, 0x8000)
    34 4266414 [main] ue 460 open: 3 = open(u, 0x8000)
   186 4266600 [main] ue 460 _cygwin_istext_for_stdio: fd 3: opened as  
binary
   232 4266832 [main] ue 460 close: close(3)
    32 4266864 [main] ue 460 fhandler_base::close: closing  
'/usr/src/ue314/bin/u' handle 0x170
    49 4266913 [main] ue 460 close: 0 = close(3)
   460 4267373 [main] 20 460 open: open(u, 0x0)

This loops some 100 times, then:

   460 4267373 [main] 20 460 open: open(u, 0x0)
    32 4267405 [main] 20 460 normalize_posix_path: src u
    32 4267437 [main] 20 460 cwdstuff::get: posix /usr/src/ue314/bin
    33 4267470 [main] 20 460 cwdstuff::get: (/usr/src/ue314/bin) =  
cwdstuff::get (0x80000008, 32768, 1, 0), errno 2
    33 4267503 [main] 20 460 normalize_posix_path: /usr/src/ue314/bin/u =  
normalize_posix_path (u)
    32 4267535 [main] 20 460 mount_info::conv_to_win32_path:  
conv_to_win32_path (/usr/src/ue314/bin/u)
    34 4267569 [main] 20 460 set_flags: flags: binary (0x2)
    32 4267601 [main] 20 460 mount_info::conv_to_win32_path: src_path  
/usr/src/ue314/bin/u, dst C:\cygwin\usr\src\ue314\bin\u, flags 0x3000A, rc  
0
    59 4267660 [main] 20 460 symlink_info::check: 0x0 = NtCreateFile  
(\??\C:\cygwin\usr\src\ue314\bin\u)
    50 4267710 [main] 20 460 symlink_info::check: not a symlink
    47 4267757 [main] 20 460 symlink_info::check: 0 =  
symlink.check(C:\cygwin\usr\src\ue314\bin\u, 0x29B598) (0x3000A)
    35 4267792 [main] 20 460 path_conv::check:  
this->path(C:\cygwin\usr\src\ue314\bin\u), has_acls(1)
    36 4267828 [main] 20 460 build_fh_pc: fh 0x61302754, dev 000000C3
    33 4267861 [main] 20 460 fhandler_base::open:  
(\??\C:\cygwin\usr\src\ue314\bin\u, 0x108000)
    72 4267933 [main] 20 460 fhandler_base::set_flags: flags 0x108000,  
supplied_bin 0x10000
    34 4267967 [main] 20 460 fhandler_base::set_flags: filemode set to  
binary
    33 4268000 [main] 20 460 fhandler_base::open: 0x0 = NtCreateFile  
(0x16C, 0x80100000, \??\C:\cygwin\usr\src\ue314\bin\u, io, NULL, 0x0, 0x7,  
0x1, 0x4020, NULL, 0)
    34 4268034 [main] 20 460 fhandler_base::open: 1 =  
fhandler_base::open(\??\C:\cygwin\usr\src\ue314\bin\u, 0x108000)
    42 4268076 [main] 20 460 fhandler_base::open_fs: 1 =  
fhandler_disk_file::open(\??\C:\cygwin\usr\src\ue314\bin\u, 0x8000)
    34 4268110 [main] 20 460 open: 3 = open(u, 0x8000)
   186 4268296 [main] 20 460 _cygwin_istext_for_stdio: fd 3: opened as  
binary
   231 4268527 [main] 20 460 close: close(3)
    33 4268560 [main] 20 460 fhandler_base::close: closing  
'/usr/src/ue314/bin/u' handle 0x16C
    49 4268609 [main] 20 460 close: 0 = close(3)
   476 4269085 [main] 2046121 460 open: open(u, 0x0)

Note the process-name gets overwritten by a number of increasing length,  
the last being 254 bytes long before the process exits.

Don't know if that's of any use. It crashed not only on cygwin.

BTW: Is there a documentation about the columns of the strace-output  
somewhere?

-Helmut

--
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

Re: TP_NUM_C_BUFS too small

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2483 bytes --]

On Nov  3 00:07, Helmut Karlowski wrote:
> Am 02.11.2015, 12:15 Uhr, schrieb Corinna Vinschen:
> 
> >>Glad it's fixed!  For the record, could you say what sort of bug would
> >>cause
> >>a fatal internal error like that?
> >>Just curious,
> >
> >Me too.  Sounds like some kind of recursion.
> 
> It all happened after I had replaced all strcpy/strcat by strlcpy like this:
> 
> strcpy(t,s) -> pos = strlcpy(t,s,size)
> strcat(t,s) -> pos += strlcpy(t+pos,s,size-pos)
> 
> At some point the pos-parameter was wrong and the resulting string became
> something undesired. And that string probably was passed to fopen, maybe pos
> became very large way beyond the boundaries of the string which is from the
> stack.
> 
> It's hard to reproduce what happened in a simple case, and I was in some
> hurry then, but I saved the strace-output:
> [...]
> fhandler_base::open(\??\C:\cygwin\usr\src\ue314\bin\u, 0x108000)
>    41 4266380 [main] ue 460 fhandler_base::open_fs: 1 =
> fhandler_disk_file::open(\??\C:\cygwin\usr\src\ue314\bin\u, 0x8000)
>    34 4266414 [main] ue 460 open: 3 = open(u, 0x8000)
>   186 4266600 [main] ue 460 _cygwin_istext_for_stdio: fd 3: opened as binary
>   232 4266832 [main] ue 460 close: close(3)
>    32 4266864 [main] ue 460 fhandler_base::close: closing
> '/usr/src/ue314/bin/u' handle 0x170
>    49 4266913 [main] ue 460 close: 0 = close(3)
>   460 4267373 [main] 20 460 open: open(u, 0x0)
                       ^^
                       !!

> This loops some 100 times, then:
> [...]
> 
> Note the process-name gets overwritten by a number of increasing length, the
> last being 254 bytes long before the process exits.

Yuk.

> Don't know if that's of any use. It crashed not only on cygwin.
> 
> BTW: Is there a documentation about the columns of the strace-output
> somewhere?

Uhm, I don't think so.  From left to right:

- usecs since last trace output

- usecs since process start

- [name of thread] (this only makes sense for the named threads,
  mainly the "main" thread, the "sig" thread, and a few short-lived
  helper threads in the DLL.  Pthreads don't have a name, they are called
  "unknown ($thread_id)"

- process name

- pid

- function/method name:

- last but not least the actual output string.


Thanks,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: TP_NUM_C_BUFS too small

[Corinna Vinschen]

On Feb  8 13:14, marco atzeri wrote:
> On Tue, Feb 8, 2011 at 12:59 PM, Corinna Vinschen  wrote:
> > On Feb  7 22:38, marco atzeri wrote:
> >> 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.

There's some chance that this is a Cygwin bug.  If you can narrow down
the problem to a specific code snippet in octave, you may be able to
extract a very simple testcase in plain C which allows to reproduce the
problem without the zillions of octave/fltk code lines.  That would be
most helpful in case it is a Cygwin problem.


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

Re: TP_NUM_C_BUFS too small

[marco atzeri]

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

Re: TP_NUM_C_BUFS too small

[Corinna Vinschen]

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

TP_NUM_C_BUFS too small

[marco atzeri]

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
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.
I suspect the error message is a red herring. Am I right ?

The plot is built as expected, so gs is doing its work; from strace output
(available on http://matzeri.altervista.org/works/octave/)
I guess that gs execution is unable to return back on octave.

Suggestion for debugging ?

gdb output is puzzling as I doubt the output code is coming from octave

"Program exited with code 030000000005."

Thank in advance
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