Re: ssh-add -l hangs under cygwin test 3.6.0-0.139.g...

[jojelino via Cygwin]

On 6/29/2024 2:39 PM, Brian Inglis via Cygwin wrote:

Reran cygport --debug upload and command hanging was ssh-add -l!

  296   72109 [main] ssh-add 63275 win32env_to_cygenv: 0xA000232E0: 
TERM_PROGRAM=mintty
  189   72298 [main] ssh-add 63275 win32env_to_cygenv: 0xA00023300: 
TERM_PROGRAM_VERSION=3.7.1


I was able to reproduce this problem by entering below command with 
ffmpeg from https://www.gyan.dev/ffmpeg/builds/ , this ffmpeg build 
spams putc. So, without piping its output to `tee', It would not 
possible track down any cause among lengthy trace output.


strace mintty -e /bin/timeout 10 sh -c './ffmpeg -h full|& tee'

In summary, When `timeout' expires, `timeout' signals SIGHUP to pgrp of 
itself, btw some member of the pgrp may have acquired any of 
synchronization object of some part of cygwin internal when a member 
process of the pgrp did encounter the signal interrupt from `timeout'. 
In my case it was output_mutex of pty.


 1565 10693297 [main] timeout 745 kill_pgrp: pid 0, signal 15
 2701 15224348 [main] mintty 744 
fhandler_pty_master::process_slave_output: bytes read 256

 1736 9525442 [sig] sh 746 proc_subproc: args: 4, 1
 3137 6700294 [main] tee 748 fhandler_pty_slave::write: pty5, 
write(0x7C780, 1024)

 1347 9526789 [sig] sh 746 proc_subproc: clear waiting threads
 2084 15226432 [main] mintty 744 
fhandler_pty_master::process_slave_output: returning 256
 1110 6701404 [main] tee 748 fhandler_pty_slave::write: (1267): pty 
output_mutex (0x4C0): waiti

-1 ms
  732 9527521 [sig] sh 746 checkstate: child_procs count 2
 3648 10696945 [main] timeout 745 open_shared: name cygpid.724, shared 
0x1A005 (wanted 0x1A

), h 0x16C, m 6, created 0
 1055 6702459 [main] tee 748 fhandler_pty_slave::write: (1267): pty 
output_mutex: acquired


 2092 15753306 [main] mintty 744 fhandler_pty_master::close: (2095): 
pty output_mutex (0x4AC):

ting -1 ms

And below is a location where `tee' did hang.

#3  0x7ffd0e408fdf in fhandler_pty_slave::write (this=0x89a10,
ptr=0x7c780, len=)
at ../../.././winsup/cygwin/fhandler/pty.cc:1268
1268  if (!process_opost_output (get_output_handle (), ptr, towrite, 
false,

(gdb)  li
1263  termios_printf ("pty%d, write(%p, %lu)", get_minor (), ptr, len);
1264
1265  push_process_state process_state (PID_TTYOU);
1266
1267  acquire_output_mutex (mutex_timeout);
1268  if (!process_opost_output (get_output_handle (), ptr, towrite, 
false,

1269 get_ttyp (), is_nonblocking ()))


I ended up prepending two CancelIo call just above of 
acquire_output_mutex located in fhandler_pty_master::close of pty.cc.


>  CancelIo(get_ttyp()->to_master());
>  CancelIo(get_ttyp()->to_master_nat());
  acquire_output_mutex (mutex_timeout);

Hope it helps


--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Bug: bash redirect "magic" variable content to input of command hangs (upstream of https://github.com/git-for-windows/git/issues/5001)

[jojelino via Cygwin]

On 6/10/2024 8:12 PM, Holger Klene via Cygwin wrote:

This is:
GNU bash, Version 5.2.21(1)-release (x86_64-pc-cygwin)

Was also reproduced in git-bash 5.2.26(1)-release (also cygwin)
but not in WSL-bash 5.1.16 (independent of cygwin)
This regression is introduced in bash-5.1, Introduced changes in both 
here-string, here-document in 5.1 caused hangs.


Apart from that, unlike to Linux, Cygwin chunks io of pipe into 64K and 
NtWriteFile writes to a pipe even after the pipe exceeded buffer size 
while reporting STATUS_PENDING, So in Cygwin, divide by 2 of actual 
buffer size is within boundary of pipe buffer as seen below.

$ dd if=/dev/urandom bs=63K status=progress | sleep 3
129024 bytes (129 kB, 126 KiB) copied, 3 s, 42.8 kB/s
$ dd if=/dev/urandom bs=128 status=progress | sleep 3
65664 bytes (66 kB, 64 KiB) copied, 3 s, 21.9 kB/s

And current bash package make wrong estimate of pipe size of host 
environment according to builtins/psize.sh of cygport source package of 
bash.



Excerpt from builtins/psize.sh of bash, You can guess what the result 
will be From the above.

./psize.aux 2>"$TMPFILE" | sleep 3



--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Segfault with detached threads and OpenSSL

[jojelino via Cygwin]

Deter using detached attribute in cygwin. for details [1].
You might find static-linking as useful workaround for this issue which 
requires build openssl from source code.


Thread 7 "a" hit Breakpoint 9, init_thread_remove_handlers (
handsin=handsin@entry=0x0) at crypto/initthread.c:178
178 if (!CRYPTO_THREAD_write_lock(gtr->lock))
(gdb) bt
#0  init_thread_remove_handlers (handsin=handsin@entry=0x0)
at crypto/initthread.c:178
#1  0x0005e03029c3 in OPENSSL_thread_stop () at crypto/initthread.c:235
#2  0x0005e03009c3 in DllMain (hinstDLL=,
fdwReason=, lpvReserved=)
at crypto/dllmain.c:38
#3  0x7ff976c49a1d in ntdll!RtlActivateActivationContextUnsafeFast ()
   from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#4  0x7ff976c475b6 in ntdll!LdrShutdownThread ()
   from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#5  0x7ff976c8468e in ntdll!RtlExitUserThread ()
   from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#6  0x7ff8e81ec987 in exit_thread (res=res@entry=0x0)
at ../../.././winsup/cygwin/sigproc.cc:544
#7  0x7ff8e81d470e in pthread::exit (this=0xa00028b90,
value_ptr=) at ../../.././winsup/cygwin/thread.cc:584
#8  0x7ff8e81d4549 in pthread::thread_init_wrapper (arg=0xa00028b90)
at ../../.././winsup/cygwin/thread.cc:2016
#9  0x7ff8e8174681 in pthread_wrapper (arg=)
at ../../.././winsup/cygwin/create_posix_thread.cc:79
#10 pthread_wrapper (arg=)
at ../../.././winsup/cygwin/create_posix_thread.cc:39


[1]
(gdb) li ../../.././winsup/cygwin/thread.cc:558
553   pthread_key::run_all_destructors ();
554
555   mutex.lock ();
556   // cleanup if thread is in detached state and not joined
557   if (equal (joiner, thread))
558 delete this;
559   else
560 {
561   valid = false;
562   return_ptr = value_ptr;

On 5/20/2024 6:29 AM, Rodrigo Arias via Cygwin wrote:

Thread 6 "p" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 7332.0x21dc]
0x in ?? ()



--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin X - Vast performance difference between X-over-ssh and xdmcp

[jojelino via Cygwin]

On 4/28/2024 4:36 AM, Jim Garrison via Cygwin wrote:
The speed difference is stark.  With X-over-ssh Eclipse is unusable, 
PyCharm barely so.  When running in an xdmcp session both are blazingly 
fast with no detectable lag.


What would make such a huge difference?


Why don't you allow Compression in sshd_config? there's no skin support 
in those IDEs..


--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Regression: Cygwin 3.5.1 freezes when launching several mingw processes in parallel

[jojelino via Cygwin]

$ (gdb|grep '+1275' -n -B10 -A10)<530 /usr/src/debug/cygwin-3.5.1-1/winsup/cygwin/pinfo.cc: No such 
file or directory.

225-
226-564 in /usr/src/debug/cygwin-3.5.1-1/winsup/cygwin/pinfo.cc
227-565 in /usr/src/debug/cygwin-3.5.1-1/winsup/cygwin/pinfo.cc
228-   0x0001800991de <+300>:   mov0x10(%rdx),%edi
229-   0x0001800991e1 <+303>:   test   %edi,%edi
230-   0x0001800991e3 <+305>:   jne0x1800991f1 
<_pinfo::set_ctty(fhandler_termios*, int)+319>

231-
232-566 in /usr/src/debug/cygwin-3.5.1-1/winsup/cygwin/pinfo.cc
233-   0x0001800991cc <+282>:   mov(%rbx),%eax
234-   0x0001800991e5 <+307>:   cmp%eax,0xfc20(%rbx)
235:   0x0001800991eb <+313>:   je 0x1800995ad 
<_pinfo::set_ctty(fhandler_termios*, int)+1275>

236-
237-567 in /usr/src/debug/cygwin-3.5.1-1/winsup/cygwin/pinfo.cc
238-568 in /usr/src/debug/cygwin-3.5.1-1/winsup/cygwin/pinfo.cc
239-569 in /usr/src/debug/cygwin-3.5.1-1/winsup/cygwin/pinfo.cc
240-570 in /usr/src/debug/cygwin-3.5.1-1/winsup/cygwin/pinfo.cc
241-   0x0001800991ce <+284>:   cmpb   $0x0,0x1ad535(%rip) 
 # 0x18024670a 
242-   0x0001800991d5 <+291>:   jne0x1800991f1 
<_pinfo::set_ctty(fhandler_termios*, int)+319>
243-   0x0001800995e6 <+1332>:  call   0x180205fa8 


244-   0x0001800995eb <+1337>:  test   %eax,%eax
245-   0x0001800995ed <+1339>:  nopl   (%rax)

On 3/1/2024 8:57 AM, jojelino via Cygwin wrote:
Line 74 of 
"/usr/src/debug/cygwin-3.5.1-1/winsup/cygwin/local_includes/tty.h"
    starts at address 0x1800995ad <_pinfo::set_ctty(fhandler_termios*, 
int)+1275> and ends at 0x1800995bb <_pinfo::set_ctty(fhandler_termios*, 
int)+1289>.



--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Regression: Cygwin 3.5.1 freezes when launching several mingw processes in parallel

[jojelino via Cygwin]

$ (echo symbol cygwin1.dll;grep -Po 
'(?<=cygwin1!)[a-z_0-9]*?\+0x[a-f0-9]*'|sed -E 's/^/i line *(/;s/$/)/')|gdb

GNU gdb (GDB) (Cygwin 12.1-1) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word".

warning: the current range check setting does not match the language.

Whether backtraces should continue past the entry point of a program is off.
(gdb) Reading symbols from cygwin1.dll...
Reading symbols from /usr/lib/debug/usr/bin/cygwin1.dll.dbg...
(gdb) 0007`c8c0 7ffe`7dc57f74 : 0008`00039b40 
0008`00039b40 `00010002 000a`0298 : 
cygwin1!dirname+0x198e
0007`c980 7ffe`7dc56a78 : `00f2f2f2 
` 0007`cd30 7ffe`e44773ae : 
cygwin1!cuserid+0x16e16
0007`c9c0 7ffe`7dc581d3 : 00ff783b`00767676 
`005b0720 `0002 0008`4870 : 
cygwin1!cuserid+0x1591a
0007`ca40 7ffe`7dbb954d : 0002`0050 
`000a3dd0 `000ab7b0 ` : 
cygwin1!cuserid+0x17075
0007`ca70 7ffe`7dbb99c2 : 0007`cc8a 
7ffe`7dba7d37 0007`cd30 0007`0c90 : 
cygwin1!dlfork+0x2695
0007`cb70 7ffe`7dba7187 : 315c615c`305c625c 
2f00735c`2e5c625c 5f5c6c5c`665c615c 745c735c`6e5c695c : 
cygwin1!dlfork+0x2b0a
0007`cbf0 7ffe`7dba5e08 : ` 
` ` ` : 
cygwin1!cygwin_dll_init+0x381
0007`cd80 7ffe`7dba5e86 : ` 
` ` ` : 
cygwin1!_assert+0x23f0
0007`cdd0 ` : 7ffe`7dd0604f 
0008`0003a210 ` 0008`00039400 : 
cygwin1!_assert+0x246e
Line 74 of 
"/usr/src/debug/cygwin-3.5.1-1/winsup/cygwin/local_includes/tty.h"
   starts at address 0x1800995ad <_pinfo::set_ctty(fhandler_termios*, 
int)+1275> and ends at 0x1800995bb <_pinfo::set_ctty(fhandler_termios*, 
int)+1289>.
(gdb) Line 1853 of 
"/usr/src/debug/cygwin-3.5.1-1/winsup/cygwin/fhandler/console.cc"

   starts at address 0x1800f7f74 
   and ends at 0x1800f7f78 .
(gdb) Line 474 of 
"/usr/src/debug/cygwin-3.5.1-1/winsup/cygwin/fhandler/base.cc"
   starts at address 0x1800f6a78 unsigned int)+312>
   and ends at 0x1800f6a7c int)+316>.
(gdb) Line 4132 of 
"/usr/src/debug/cygwin-3.5.1-1/winsup/cygwin/fhandler/console.cc"
   starts at address 0x1800f81d3 unsigned int, unsigned int)+73>
   and ends at 0x1800f81de unsigned int)+84>.

(gdb) Line 407 of "/usr/src/debug/cygwin-3.5.1-1/winsup/cygwin/dtable.cc"
   starts at address 0x18005954d 

   and ends at 0x180059555 void*)+1019>.

(gdb) Line 186 of "/usr/src/debug/cygwin-3.5.1-1/winsup/cygwin/dtable.cc"
   starts at address 0x1800599b0 
   and ends at 0x1800599c3 .
(gdb) Line 928 of "/usr/src/debug/cygwin-3.5.1-1/winsup/cygwin/dcrt0.cc"
   starts at address 0x180047187 
   and ends at 0x180047191 .
(gdb) No symbol "_assert" in current context.
(gdb) No symbol "_assert" in current context.
(gdb)
quit

On 3/1/2024 6:34 AM, Kevin Schnitzius via Cygwin wrote:

STACK_TEXT:
0007`c8c0 7ffe`7dc57f74 : 0008`00039b40
0008`00039b40 `00010002 000a`0298 :
cygwin1!dirname+0x198e
0007`c980 7ffe`7dc56a78 : `00f2f2f2
` 0007`cd30 7ffe`e44773ae :
cygwin1!cuserid+0x16e16
0007`c9c0 7ffe`7dc581d3 : 00ff783b`00767676
`005b0720 `0002 0008`4870 :
cygwin1!cuserid+0x1591a
0007`ca40 7ffe`7dbb954d : 0002`0050
`000a3dd0 `000ab7b0 ` :
cygwin1!cuserid+0x17075
0007`ca70 7ffe`7dbb99c2 : 0007`cc8a
7ffe`7dba7d37 0007`cd30 0007`0c90 :
cygwin1!dlfork+0x2695
0007`cb70 7ffe`7dba7187 : 315c615c`305c625c
2f00735c`2e5c625c 5f5c6c5c`665c615c 745c735c`6e5c695c :
cygwin1!dlfork+0x2b0a
0007`cbf0 7ffe`7dba5e08 : `
` ` ` :
cygwin1!cygwin_dll_init+0x381
0007`cd80 7ffe`7dba5e86 : `
` ` ` :
cygwin1!_assert+0x23f0
0007`cdd0 ` : 7ffe`7dd0604f
0008`0003a210 ` 0008`00039400 :
cygwin1!_assert+0x246e



--
P

Re: Regression: Cygwin 3.5.1 freezes when launching several mingw processes in parallel

[jojelino via Cygwin]

$ (echo symbol cygwin1.dll;grep -Po 
'(?<=cygwin1!)[a-z_0-9]*?\+0x[a-f0-9]*'|sed -E 's/^/i line *(/;s/$/)/')|gdb

GNU gdb (GDB) (Cygwin 12.1-1) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word".

warning: the current range check setting does not match the language.

Whether backtraces should continue past the entry point of a program is off.
(gdb) Reading symbols from cygwin1.dll...
Reading symbols from /usr/lib/debug/usr/bin/cygwin1.dll.dbg...
(gdb) 0007`c8c0 7ffe`7dc57f74 : 0008`00039b40 
0008`00039b40 `00010002 000a`0298 : 
cygwin1!dirname+0x198e
0007`c980 7ffe`7dc56a78 : `00f2f2f2 
` 0007`cd30 7ffe`e44773ae : 
cygwin1!cuserid+0x16e16
0007`c9c0 7ffe`7dc581d3 : 00ff783b`00767676 
`005b0720 `0002 0008`4870 : 
cygwin1!cuserid+0x1591a
0007`ca40 7ffe`7dbb954d : 0002`0050 
`000a3dd0 `000ab7b0 ` : 
cygwin1!cuserid+0x17075
0007`ca70 7ffe`7dbb99c2 : 0007`cc8a 
7ffe`7dba7d37 0007`cd30 0007`0c90 : 
cygwin1!dlfork+0x2695
0007`cb70 7ffe`7dba7187 : 315c615c`305c625c 
2f00735c`2e5c625c 5f5c6c5c`665c615c 745c735c`6e5c695c : 
cygwin1!dlfork+0x2b0a
0007`cbf0 7ffe`7dba5e08 : ` 
` ` ` : 
cygwin1!cygwin_dll_init+0x381
0007`cd80 7ffe`7dba5e86 : ` 
` ` ` : 
cygwin1!_assert+0x23f0
0007`cdd0 ` : 7ffe`7dd0604f 
0008`0003a210 ` 0008`00039400 : 
cygwin1!_assert+0x246e
Line 74 of 
"/usr/src/debug/cygwin-3.5.1-1/winsup/cygwin/local_includes/tty.h"
   starts at address 0x1800995ad <_pinfo::set_ctty(fhandler_termios*, 
int)+1275> and ends at 0x1800995bb <_pinfo::set_ctty(fhandler_termios*, 
int)+1289>.
(gdb) Line 1853 of 
"/usr/src/debug/cygwin-3.5.1-1/winsup/cygwin/fhandler/console.cc"

   starts at address 0x1800f7f74 
   and ends at 0x1800f7f78 .
(gdb) Line 474 of 
"/usr/src/debug/cygwin-3.5.1-1/winsup/cygwin/fhandler/base.cc"
   starts at address 0x1800f6a78 unsigned int)+312>
   and ends at 0x1800f6a7c int)+316>.
(gdb) Line 4132 of 
"/usr/src/debug/cygwin-3.5.1-1/winsup/cygwin/fhandler/console.cc"
   starts at address 0x1800f81d3 unsigned int, unsigned int)+73>
   and ends at 0x1800f81de unsigned int)+84>.

(gdb) Line 407 of "/usr/src/debug/cygwin-3.5.1-1/winsup/cygwin/dtable.cc"
   starts at address 0x18005954d 

   and ends at 0x180059555 void*)+1019>.

(gdb) Line 186 of "/usr/src/debug/cygwin-3.5.1-1/winsup/cygwin/dtable.cc"
   starts at address 0x1800599b0 
   and ends at 0x1800599c3 .
(gdb) Line 928 of "/usr/src/debug/cygwin-3.5.1-1/winsup/cygwin/dcrt0.cc"
   starts at address 0x180047187 
   and ends at 0x180047191 .
(gdb) No symbol "_assert" in current context.
(gdb) No symbol "_assert" in current context.
(gdb)
quit


On 3/1/2024 6:34 AM, Kevin Schnitzius via Cygwin wrote:

On Thursday, February 29, 2024 at 01:21:01 PM EST, Kate Deplaix via Cygwin 
 wrote:

At some point of the make process, one job will infinit loop (taking 100% of 
one core), while the rest of the mingw jobs will idle and never finish. After 
some time Cygwin Terminal isn't
responsive anymore, and I'm not able to open another one or to spawn any other 
processes that are relying on the cygwin dll. I was able to observe this 
behaviour every time i tried
consistently.


I have repro'd this problem with the exception that there was no 100% cpu 
usage.  Looks like an exception handling loop:

(2c20.4df8): Access violation - code c005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
cygwin1!dirname+0x198e:
7ffe`7dbf95ad 458b5c2408  mov r11d,dword ptr [r12+8] 
ds:0001`a0030008=
0:000> g
(2c20.4df8): Access violation - code c005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
cygwin1!dirname+0x198e:
7ffe`7dbf95ad 458b5c2408  mov r11d,dword ptr [r12+8] 
ds:0001`a0030008=
0:000> g
(2c20.4df8): Access violation - code c005 (first chance)
First chance exc

Re: Python C Extension Module loading issue on Cygwin

[jojelino via Cygwin]

On 9/22/2023 3:39 PM, Mesibo Technical via Cygwin wrote:

Any idea why Cygwin is using the .dll extension instead of the .pyd
extension as recommended by Python's official documentation?


$ grep "_SUFFIX=" /usr/lib/python3.9/config-3.9-x86_64-cygwin/Makefile
SHLIB_SUFFIX=   .dll
EXT_SUFFIX= .cpython-39-x86_64-cygwin.dll

Your speculation is quite weird, Normally you don't have no problem 
loading extension module without suffix in python. and paragraph like 
(eg,) is regarded as neither exhaustive or authoritative.


How about look through source code of distutils,setuptools,cpython 
instead of complaining about software without any warranty(according to 
PSF license)?




--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: abort during exit() with a dynamically loaded C++ library

[jojelino]

On 2014-07-07 PM 10:58, Jon TURNEY wrote:

On 17/06/2014 19:11, Jon TURNEY wrote:

I think I have found a problem when building programs using the latest
mesa library, where abort is being called during exit()


The main concern of this crash is the order mismatch between loading and 
unloading dynamic library. It seems that either crtbegin or crtend code 
of i386 libgcc has some pitfall. The mismatch always occurs when main() 
didn't statically link to libgcc.


If my memory serves me correctly, static version of deregister_frame_fn 
is set to wrong address (see cygming-crtbegin.c) by unknown fallacy of 
gnu-ld linker. That is, Object file seems okay, But generated dll breaks 
offset argument resulting in invalid offset operand of memory 
references, although Kai Tietz said in 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57680 that It had been fixed.


Until the fallacy of gnu-ld is being resolved by someone that has plenty 
of time or someone have workaround against the fallacy of 
ever-not-warranted linker, I'll suggest you to just call 
dlopen("cyggcc_s-1") before dlopen'ing any DLL that has dynamic linkage 
to libgcc. It would be okay for workarounding the problem.

--
Regards.


--
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: Severe performance degradation of writev

[jojelino]

On 2014-07-07 AM 7:28, jojelino wrote:

svnrdump dump --incremental http://svn.apache.org/repos/asf/subversion
subversion

Instead of above the wrong one, this
svnrdump dump --incremental http://svn.apache.org/repos/asf/subversion > 
/dev/null


--
Regards.


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

Severe performance degradation of writev

[jojelino]

2008-07-27  Corinna Vinschen  

   * fhandler_socket.cc (fhandler_socket::send_internal): Send 
never more
   then 64K bytes at once.  For blocking sockets, loop until entire 
data

   has been sent or an error occurs.
   (fhandler_socket::sendto): Drop code which sends on 64K bytes.
   (fhandler_socket::sendmsg): Ditto.

This commit added workaround for KB823764. but it has brought another 
performance issue when writev sends <64k of data.

Execute following command shows the problem.
svnrdump dump --incremental http://svn.apache.org/repos/asf/subversion 
subversion
cygwin does split writev request into many WSASendTo call and serf 
library sets TCP_NODELAY for socket it uses, a WSASendTo call 
corresponds to a tcp packet.
You can see that http header is sent being splitted when you executed 
above command. Whereas win32 backend of apr library doesn't exhibit such 
behavior by using send call.

--
Regards.


--
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: gcc-4.8.2-1: /bin/gcc fails

[jojelino]

On 2013-11-23 AM 4:02, jojelino wrote:

On 2013-11-02 PM 3:23, David Rothenberger wrote:
This problem is caused by zero-byte of
${builddir}/host-i686-pc-cygwin/specs
and the specs file is created by bootstrapped gcc executable.
the bootstrapped gcc crashes when generating specs file, which is the
cause of the problem mentioned in this report. the maintainer of gcc
should have experienced this problem.
to workaround this problem, the package maintainer needed to supress
C{XX}FLAGS -static-libgcc -static-libstdc++ in
host-i686-pc-cygwin/gcc/Makefile.


Appending --with-boot-ldflags="   " --with-stage1-ldflags="   " to 
configure argument [1] might work instead of doing nasty stuff to Makefile.


[1] http://gcc.gnu.org/install/configure.html
--
Regards.


--
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: gcc-4.8.2-1: /bin/gcc fails

[jojelino]

On 2013-11-02 PM 3:23, David Rothenberger wrote:

With gcc-4.8.2-1, the following fails:

% touch /tmp/t.c
% /bin/gcc -c /tmp/t.c
gcc: error: spawn: No such file or directory

This works correctly if gcc is invoked as "gcc" or "/usr/bin/gcc".
It also works correctly with 4.8.1.

It appears this is due to a change from /usr/lib to /usr/libexec.
/bin/gcc attempts to find cc1 under "/bin/../libexec/...". In 4.8.1,
this was "/bin/../lib/...", which works because /lib is mapped to
/usr/lib by Cygwin. /usr/bin/gcc uses "/usr/bin/../libexec" which
also works fine.

I can work around the problem as follows:

% ln -s /libexec /usr/libexec

This problem is caused by zero-byte of 
${builddir}/host-i686-pc-cygwin/specs

and the specs file is created by bootstrapped gcc executable.
the bootstrapped gcc crashes when generating specs file, which is the 
cause of the problem mentioned in this report. the maintainer of gcc 
should have experienced this problem.
to workaround this problem, the package maintainer needed to supress 
C{XX}FLAGS -static-libgcc -static-libstdc++ in 
host-i686-pc-cygwin/gcc/Makefile.

--
Regards.


--
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: sqlite defect

[jojelino]

On 2013-07-19 PM 9:08, jojelino wrote:

On 2013-07-19 PM 9:02, Corinna Vinschen wrote:

There *is* a workaround:

   export CYGWIN_SQLITE_LOCKING=posix

See http://cygwin.com/ml/cygwin-announce/2013-06/msg00014.html


It's very good workaround instead of rebuild sqlite3. thanks for the point.
Also, I commented out F_LCK_MANDATORY in fcntl.h to keep from 
confronting the disastrous situation introduced by this experimental 
feature. I expect it would save many hours instead of digging into 
unmaintained source codes. especially for projects that uses the sort of 
autotools which just checks the existence of F_LCK_MANDATORY macro. and 
is optimistic about the experimental feature.

--
Regards.


--
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: sqlite defect

[jojelino]

On 2013-07-19 PM 9:02, Corinna Vinschen wrote:

There *is* a workaround:

   export CYGWIN_SQLITE_LOCKING=posix

See http://cygwin.com/ml/cygwin-announce/2013-06/msg00014.html


It's very good workaround instead of rebuild sqlite3. thanks for the point.
--
Regards.


--
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: sqlite defect

[jojelino]

On 2013-07-19 PM 8:30, Corinna Vinschen wrote:

A valid testcase would help a lot, though.  What you meant to do
was calling flock with LOCK_EX|LOCK_NB.

that's what exactly sqlite3 that uses the mandatory-locking did. 
reproducing the behavior was i meant to do.

And then again, your testcase works as designed.  Not by me, but by
Microsoft.  You can't overwrite an existing lock, even if hold by the
same file handle.  See http://cygwin.com/cygwin-api/std-notes.html

Yes. the testcase works without mandatory locking. so i hope next 
sqlite3 release doesn't use mandatory locking feature of cygwin. someone 
who have plenty of time to waste digging into sqlite3 source code would 
come with workaround to the problem.


Corinna




--
Regards.


--
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: sqlite defect

[jojelino]

On 2013-07-19 PM 7:08, Corinna Vinschen wrote:
> ...and, btw., fcntl(fd, F_SETOWN) is only supported on sockets.
>
>
> Corinna
>
28 55977555 [main] python 5616 open: 9 = 
open(/home/Administrator/../..sqlite, 0x58202)

..
..
 4680 55982813 [main] python 5616 flock: 0 = flock(9, 6)
..
..
   35 55983687 [main] python 5616 seterrno_from_nt_status: 
/netrel/src/cygwin-snapshot-20130619-1/winsup/cygwin/flock.cc:2020 
status 0xC055 -> windows error 33
   26 55983713 [main] python 5616 geterrno_from_win_error: windows 
error 33 == errno 16

   24 55983737 [main] python 5616 flock: -1 = flock(9, 6), errno 16

I tried reproducing above failure.
--
Regards.


--
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: sqlite defect

[jojelino]

On 2013-07-18 PM 5:59, Corinna Vinschen wrote:> On Jul 18 17:11, 
jojelino wrote:

>> On 2013-07-18 AM 10:53, Warren Young wrote:
>>> Nothing so simple.  Locking is handled at the OS and/or Cygwin DLL
>>> level.  The build change between 3.7.16.2 and 3.7.17-3 is that 
we're now
>>> relying on new features in the Cygwin DLL to do Windows-style 
locking by

>>> default.
>>>
>>> Older versions of Cygwin SQLite bypassed the Cygwin DLL entirely for
>>> this, going straight to the Win32 API, thereby preventing the DLL from
>>> interposing itself for the "posix" case.
>>>
>> Mandatory locking feature of cygwin used in sqlite is broken.
>
> Simple testcase in plain C?
>
>
> Corinna
>
#include 
#include 
#include 
#include 
#include 
int
main()
{
  int fd = open("asdf.txt", O_BINARY | O_RDWR | O_NOINHERIT | O_CREAT);
  const char* buf = 
"K\0";

  int i=0;
  write(fd, buf, strlen(buf));
  fcntl(fd,F_LCK_MANDATORY,0);
  assert(flock(fd,F_SETOWN)==0);
  assert(flock(fd,F_SETOWN)==0);
  assert(flock(fd,LOCK_NB|LOCK_UN)==0);
  fcntl(fd,F_LCK_MANDATORY,1);
  assert(flock(fd,F_SETOWN)==0);
  assert(flock(fd,LOCK_NB|LOCK_UN)==0);
  assert(flock(fd,F_SETOWN)==0);
  assert(flock(fd,F_SETOWN)==0); /* assertion "flock(fd,F_SETOWN)==0" 
failed: file "f_lck.c", line 28, function: main */

  return 0;
}

/**/
--
Regards.


--
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: sqlite defect

[jojelino]

On 2013-07-18 AM 10:53, Warren Young wrote:

Nothing so simple.  Locking is handled at the OS and/or Cygwin DLL
level.  The build change between 3.7.16.2 and 3.7.17-3 is that we're now
relying on new features in the Cygwin DLL to do Windows-style locking by
default.

Older versions of Cygwin SQLite bypassed the Cygwin DLL entirely for
this, going straight to the Win32 API, thereby preventing the DLL from
interposing itself for the "posix" case.


Mandatory locking feature of cygwin used in sqlite is broken.
Just build plain sqlite build without the cygport patch that led the 
disaster. unless you have familiar with exotic adventure like finding 
undocumented behavior of windows wasting many man-hours to workaround 
the problem.


--
Regards.


--
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: clang++ broken by recent GCC update

[jojelino]

On 2013-07-04 PM 9:47, Václav Zeman wrote:> Hi.
>
> The C++ part of Clang package (I have not tested the C part) is broken
> after update of GCC to 4.7.3. It cannot find standard C++ headers:
>
>
Clang does use hard-coded include path for using gcc header files.
Please build your own or you can file bug report to clang.

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

gdb hangs when it calls tcsetpgrp.

[jojelino]

I was using gdb for debugging ffmpeg raising SIGFPE. but gdb hangs after 
entering command among of s,n,si,ni.
gdb has same pgrp over pgrp of debuggee. when tcsetpgrp is called in 
gdb, you already know it sends __SIGSETPGRP signal to suspended 
debuggee. but the debugger already suspended all thread of debuggee 
without distinguishing whether the victim thread is wait_sig or not. so 
the suspend process doesn't wake up until debugger handles debug event. 
which is the cause of hang.
Although it seems that cygwin developers have already aware of sort of 
this issue according to fhandler_termios.cc:85, so, it would be good if 
cygwin can defer sending signal that would block for sure.


--
Regards.


--
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: SIGQUIT reported as SIGSEGV

[jojelino]

On 2013-04-30 PM 9:37, Helmut Karlowski wrote:

Daniel R. Grayson, 30.04.2013 14:11:19:


SIGQUIT is erroneously delivered as SIGSEGV in this circumstance:

$ sleep 1000 &
[1] 9148
$ kill -QUIT %1
$< press return if necessary here >
[1]+  Segmentation fault  (core dumped) sleep 1000


It's sleep.exe that crashes, the report is correct.

Stack trace:
Frame Function  Args
0022AAC8  7C80A115  (0003, 0022AB2C, , )


--- Process 7188, exception C005 at 6102F813
sh-4.1$ addr2line -e /bin/cygwin1.dbg
6102F813
/netrel/src/cygwin-snapshot-20130409-1/winsup/cygwin/exceptions.cc:252

It's long-standing bug during stack backtrace in cygwin. if any frame 
has used ebp for purposes other than frame pointer. which is mostly the 
case.

--
Regards.


--
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: Debugging totally broken with latest everything?

[jojelino]

On 2013-04-16 AM 1:03, Dave Korn wrote:

Thread 2 (Thread 5536.0xe2c):
#0  0x77f88a87 in ntdll!ZwReadFile () from /win/c/WINNT/system32/ntdll.dll
#1  0x7c586381 in ?? ()
#2  0x610dd075 in wait_sig ()
 at /usr/src/debug/cygwin-1.7.17-1/winsup/cygwin/sigproc.cc:1360
#3  0x61003e65 in cygthread::callfunc (this=0x6118a400 ,
 issimplestub=)
 at /usr/src/debug/cygwin-1.7.17-1/winsup/cygwin/cygthread.cc:51
#4  0x610043ef in cygthread::stub (arg=0x6118a400 )
 at /usr/src/debug/cygwin-1.7.17-1/winsup/cygwin/cygthread.cc:93
#5  0x6100533d in _cygtls::call2 (this=,
 func=0x610043a0 , arg=0x6118a400 ,
 buf=0x610054cb <_cygtls::call(unsigned long (*)(void*, void*), void*)+91>)
 at /usr/src/debug/cygwin-1.7.17-1/winsup/cygwin/cygtls.cc:99
#6  0x0270ffb4 in ?? ()
#7  0x7c57b3bc in ?? ()
#8  0x in ?? ()

Thread 1 (Thread 5536.0x1640):
#0  0x77f88f43 in ntdll!ZwWriteFile () from /win/c/WINNT/system32/ntdll.dll
#1  0x7c5864f9 in ?? ()
#2  0x610dc3f4 in sig_send (p=0x14ea444, si=..., tls=0x0)
 at /usr/src/debug/cygwin-1.7.17-1/winsup/cygwin/sigproc.cc:736
#3  0x6106b028 in tty_min::kill_pgrp (this=0x60fc, sig=-43)
 at /usr/src/debug/cygwin-1.7.17-1/winsup/cygwin/fhandler_termios.cc:133
#4  0x6106b129 in fhandler_termios::tcsetpgrp (
 this=0x61274690 <__real__Znwj+1629963920>, pgid=2428)
 at /usr/src/debug/cygwin-1.7.17-1/winsup/cygwin/fhandler_termios.cc:85
#5  0x610f9f78 in tcsetpgrp (fd=0, pgid=2428)
 at /usr/src/debug/cygwin-1.7.17-1/winsup/cygwin/termios.cc:237
#6  0x610d6745 in _sigfe () from /usr/bin/cygwin1.dll
#7  0x200bbb70 in ?? ()
#8  0x00418662 in ?? ()
#9  0x00521908 in ?? ()
#10 0x004eb052 in ?? ()
---Type  to continue, or q  to quit---
#11 0x004eb265 in ?? ()
#12 0x004dd4a0 in ?? ()
#13 0x004dd6a5 in ?? ()
#14 0x005b11ab in ?? ()
#15 0x004feccb in ?? ()
#16 0x004ff6c0 in ?? ()
#17 0x005f2de2 in ?? ()
#18 0x004fed3b in ?? ()
#19 0x004fd9a0 in ?? ()
#20 0x004fdfc4 in ?? ()
#21 0x004fe4b8 in ?? ()
#22 0x004fe537 in ?? ()
#23 0x004f8345 in ?? ()
#24 0x004f6e0a in ?? ()
#25 0x004f8a85 in ?? ()
#26 0x004f6e0a in ?? ()
#27 0x004f9632 in ?? ()
#28 0x004011a8 in ?? ()
#29 0x6100763a in _cygwin_exit_return ()
 at /usr/src/debug/cygwin-1.7.17-1/winsup/cygwin/dcrt0.cc:974
#30 0x6100533d in _cygtls::call2 (this=,
 func=0x61006c50 , arg=0x0,
 buf=0x610054cb <_cygtls::call(unsigned long (*)(void*, void*), void*)+91>)
 at /usr/src/debug/cygwin-1.7.17-1/winsup/cygwin/cygtls.cc:99
#31 0x014eff78 in ?? ()
#32 0x006c1df2 in ?? ()
#33 0x00401015 in ?? ()
#34 0x7c5989d5 in ?? ()
#35 0x in ?? ()
(gdb)


   Some notes on the above:

   The same happens with both the previous version and current snapshot of the
cygwin dll.  It also happens with both current gdb and an old gdb
6.8.0.20080328-cvs that I have lying around.

   The hw.exe in question is your bog-standard hello world, compiled with "-g
-O0" using gcc4-4.5.3-3.

   "kill -9" won't kill gdb; I have to use Windows task manager.  If I've
attached gdb to the hung gdb, I can kill it from there using the "k" 
instruction.

   Anyone else having similar problems?

 cheers,
   DaveK



As far as i know, wait_sig thread in debugee is interrupted after 
stepping or breakpoint( n s si ni ). so, if you don't give cygwin 
sufficient time during gdb session until wait_sig thread handles signal 
about terminal, it hangs like you observed.


--
Regards.


--
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: Hang on CTRL-C (was Re: livelock on sigfe)

[jojelino]

On 2013-04-01 PM 2:03, Christopher Faylor wrote:

On Mon, Apr 01, 2013 at 11:53:38AM +0900, jojelino wrote:

On 2013-03-17 AM 1:44, Christopher Faylor wrote:

No, not really.  The caller in this case isn't interesting.  The number
of threads executing is interesting.

cgf


there is another debug session. I was trying to CTRL+C to mintty session
in which make process was running. process hanged with livelock.



make process got CTRL+C, and the hanged was clang.exe. and these two was 
on mintty session.



Sorry for being so precise in my request that you provide information
on threads. It sure would be nice to see what thread 3 was doing via
a backtrace.

cgf



Here it is. this was created when gdb attached the process.
(gdb) i threads
  Id   Target Id Frame
* 3Thread 4516.0xc78 0x7c95a22a in ntdll!DbgBreakPoint ()
   from /cygdrive/c/WINDOWS/system32/ntdll.dll
  2Thread 4516.0x1310 0x7c96845c in ntdll!KiFastSystemCallRet ()
   from /cygdrive/c/WINDOWS/system32/ntdll.dll
  1Thread 4516.0x1e88 0x7c96845c in ntdll!KiFastSystemCallRet ()
   from /cygdrive/c/WINDOWS/system32/ntdll.dll
(gdb) bt
#0  0x7c95a22a in ntdll!DbgBreakPoint ()
   from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1  0x7c97fc68 in ntdll!DbgUiRemoteBreakin ()
   from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2  0x0005 in ?? ()
#3  0x88617518 in ?? ()
#4  0x in ?? ()
#5  0x7c9680e0 in ntdll!_CIpow () from 
/cygdrive/c/WINDOWS/system32/ntdll.dll

#6  0x7c97fc80 in ntdll!DbgUiRemoteBreakin ()
   from /cygdrive/c/WINDOWS/system32/ntdll.dll
#7  0x in ?? ()
(gdb)

--
Regards.
--
Regards.


--
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: livelock on sigfe

[jojelino]

On 2013-03-17 AM 1:44, Christopher Faylor wrote:

No, not really.  The caller in this case isn't interesting.  The number
of threads executing is interesting.

cgf

there is another debug session. I was trying to CTRL+C to mintty session 
in which make process was running. process hanged with livelock.


After inspecting cygtls content, i found that the two thread have empty 
cygtls stack. so i couldn't figure out caller of _sigfe barrier, there 
is no opportunity to pop stack of thread 1(which is main thread trapped 
in sigfe wait loop), wait_sig thread or CTRL+C handler should have 
caused bizzare.


GNU gdb (GDB) 7.5.50.20130309-cvs (cygwin-special)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-cygwin".
For bug reporting instructions, please see:
.

warning: the current range check setting does not match the language.

Whether backtraces should continue past the entry point of a program is off.
Attaching to process 4516
[New Thread 4516.0x1e88]
[New Thread 4516.0x1310]
[New Thread 4516.0xf74]
Reading symbols from /usr/bin/clang.exe...(no debugging symbols 
found)...done.

(gdb) i thr
  Id   Target Id Frame
* 3Thread 4516.0xf74 0x7c95a22a in ntdll!DbgBreakPoint ()
   from /cygdrive/c/WINDOWS/system32/ntdll.dll
  2Thread 4516.0x1310 0x7c96845c in ntdll!KiFastSystemCallRet ()
   from /cygdrive/c/WINDOWS/system32/ntdll.dll
  1Thread 4516.0x1e88 0x7c96845c in ntdll!KiFastSystemCallRet ()
   from /cygdrive/c/WINDOWS/system32/ntdll.dll
(gdb) i thr
  Id   Target Id Frame
* 3Thread 4516.0xf74 0x7c95a22a in ntdll!DbgBreakPoint ()
   from /cygdrive/c/WINDOWS/system32/ntdll.dll
  2Thread 4516.0x1310 0x7c96845c in ntdll!KiFastSystemCallRet ()
   from /cygdrive/c/WINDOWS/system32/ntdll.dll
  1Thread 4516.0x1e88 0x7c96845c in ntdll!KiFastSystemCallRet ()
   from /cygdrive/c/WINDOWS/system32/ntdll.dll
(gdb) thr 2
[Switching to thread 2 (Thread 4516.0x1310)]
#0  0x7c96845c in ntdll!KiFastSystemCallRet ()
   from /cygdrive/c/WINDOWS/system32/ntdll.dll
(gdb) bt
#0  0x7c96845c in ntdll!KiFastSystemCallRet ()
   from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1  0x7c967409 in ntdll!ZwQueryInformationThread ()
   from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2  0x7c8325db in KERNEL32!GetThreadPriority ()
   from /cygdrive/c/WINDOWS/system32/kernel32.dll
#3  0x610878b1 in yield ()
at 
/netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/miscfuncs.cc:243

#4  0x610d7354 in _cygtls::lock() () from /usr/bin/cygwin1.dll
#5  0x6103096e in sigpacket::setup_handler (this=0x355ac34,
handler=0x6102fe00 , siga=..., 
tls=0x22ce64)
at 
/netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/exceptions.cc:796

#6  0x610318ff in sigpacket::process (this=0x355ac34)
at 
/netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/exceptions.cc:1245

#7  0x610dd74c in wait_sig ()
at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/sigproc.cc:1389
#8  0x61003ea5 in cygthread::callfunc (this=0x6118b420 ,
issimplestub=)
at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/cygthread.cc:51
#9  0x6100442f in cygthread::stub (arg=0x6118b420 )
at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/cygthread.cc:93
#10 0x6100537d in _cygtls::call2 (this=,
func=0x610043e0 , arg=0x6118b420 ,
buf=0x6100551b <_cygtls::call(unsigned long (*)(void*, void*), 
void*)+91>)

---Type  to continue, or q  to quit---
at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/cygtls.cc:99
#11 0x0355ffb8 in ?? ()
#12 0x7c82484f in KERNEL32!GetModuleHandleA ()
   from /cygdrive/c/WINDOWS/system32/kernel32.dll
#13 0x in ?? ()
(gdb) thr 1
[Switching to thread 1 (Thread 4516.0x1e88)]
#0  0x7c96845c in ntdll!KiFastSystemCallRet ()
   from /cygdrive/c/WINDOWS/system32/ntdll.dll
(gdb) bt
#0  0x7c96845c in ntdll!KiFastSystemCallRet ()
   from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1  0x7c9678c9 in ntdll!ZwSetInformationThread ()
   from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2  0x7c8324f9 in SetThreadPriority ()
   from /cygdrive/c/WINDOWS/system32/kernel32.dll
#3  0x610878cb in yield ()
at 
/netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/miscfuncs.cc:244

#4  0x610d723c in _sigfe () from /usr/bin/cygwin1.dll
#5  0x61083420 in lfind () from /usr/bin/cygwin1.dll
#6  0x61006cf5 in dll_crt0_1 ()
at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/dcrt0.cc:861
#7  0x6100537d in _cygtls::call2 (this=,
func=0x61006c50 , arg=0x0,
buf=0x6100551b <_cygtls::call(unsigned long (*)(void*, void*), 
void*)+91>)

at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/cygtls.cc:99
#8  0x0022ff78 in ?? ()
#9  0x01040752 in ?? ()
#10 0x00401015 in ?? ()
#1

Re: deadlock with busy waiting on sigfe

[jojelino]

On 2013-03-16 AM 10:46, jojelino wrote:

On 2013-03-16 AM 4:41, Christopher Faylor wrote:

On Mon, Mar 11, 2013 at 04:45:54PM -0400, Christopher Faylor wrote:
Actually, if you are running this on a DOS console, and you hit CTRL-C,
you will have at least one other thread executing.

Were you running this under mintty (aka a pty) or in a Windows cmd
shell?

cgf


It was mintty i was running. and shell command was
for i in `seq 1`;do ./hop.py list.txt ;done

And it would take at least another month to reproduce the busy wait.
I forgot to print cygtls::stackptr[-1] at that time. which would be key 
to identify the cause of the problem.


--
Regards.


--
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: deadlock with busy waiting on sigfe

[jojelino]

On 2013-03-16 AM 4:41, Christopher Faylor wrote:

On Mon, Mar 11, 2013 at 04:45:54PM -0400, Christopher Faylor wrote:
Actually, if you are running this on a DOS console, and you hit CTRL-C,
you will have at least one other thread executing.

Were you running this under mintty (aka a pty) or in a Windows cmd
shell?

cgf


It was mintty i was running. and shell command was
for i in `seq 1`;do ./hop.py list.txt ;done
--
Regards.


--
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: gdb bt gives many question marks

[jojelino]

On 2013-03-14 PM 6:30, Ken Huang wrote:

2013/3/14 jojelino :

On 2013-03-14 PM 4:37, Ken Huang wrote:


Hi all,

I have a problem when using gdb to debug my program in cygwin, the 'bt'
command
gives me many '??'.
(gdb) bt full
#0  0x7c92e514 in ntdll!LdrAccessResource () from
/cygdrive/c/WINDOWS/system32/ntdll.dll
No symbol table info available.
#1  0x7c92df5a in ntdll!ZwWaitForSingleObject () from
/cygdrive/c/WINDOWS/system32/ntdll.dll
No symbol table info available.
#2  0x7c8025db in WaitForSingleObjectEx () from
/cygdrive/c/WINDOWS/system32/kernel32.dll
No symbol table info available.
#3  0x0714 in ?? ()
No symbol table info available.
#4  0x in ?? ()
No symbol table info available.

My test program is as follows:
void bar()
{
  abort();
}

void foo()
{
  bar();
}

int main()
{
  foo();
}

So, did I compile wrong, or is there something I didn't set properly?

Thanks,
Ken



There is no way of identifying stdcall or fastcall ABI for return address
that are not annotated by DWARF contained in stack frames in current gdb.
you'd better give up or come with patches that solved the problem.
--
Regards.


So you mean gdb can't help to debug buggy code without patches? but as the
results I googled before, there are people out there use gdb just like in linux.

Do I need to install some external packages?

Regards,
Ken

Yes. this is problem of gdb and it failed to detect ebp based stack 
frame. if you wanted figuring out whether SIGABRT signal correctly 
points your code that called abort() then your post clearly revealed 
that it didn't work. and i can't say any external package can be used to 
resolve this problem.

--
Regards.


--
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: gdb bt gives many question marks

[jojelino]

On 2013-03-14 PM 4:37, Ken Huang wrote:

Hi all,

I have a problem when using gdb to debug my program in cygwin, the 'bt' command
gives me many '??'.
(gdb) bt full
#0  0x7c92e514 in ntdll!LdrAccessResource () from
/cygdrive/c/WINDOWS/system32/ntdll.dll
No symbol table info available.
#1  0x7c92df5a in ntdll!ZwWaitForSingleObject () from
/cygdrive/c/WINDOWS/system32/ntdll.dll
No symbol table info available.
#2  0x7c8025db in WaitForSingleObjectEx () from
/cygdrive/c/WINDOWS/system32/kernel32.dll
No symbol table info available.
#3  0x0714 in ?? ()
No symbol table info available.
#4  0x in ?? ()
No symbol table info available.

My test program is as follows:
void bar()
{
 abort();
}

void foo()
{
 bar();
}

int main()
{
 foo();
}

So, did I compile wrong, or is there something I didn't set properly?

Thanks,
Ken



There is no way of identifying stdcall or fastcall ABI for return 
address that are not annotated by DWARF contained in stack frames in 
current gdb. you'd better give up or come with patches that solved the 
problem.

--
Regards.


--
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: deadlock with busy waiting on sigfe

[jojelino]

On 2013-03-12 AM 4:35, jojelino wrote:

I was trying to CTRL+C cygwin python process that is executing some
operation and fell asleep for 60 seconds repeatedly. I'm pretty sure
that the process was sleeping as i tried interrupt it.
And some operation includes making connection to localhost tcp server 
and sending some command to that. so another thread would be 
mswsock!SockAsyncThread.

this case was very rare and i rarely saw the livelock except this time.
#! /usr/bin/python
from telnetlib import *
import re,sys,time,datetime
t=Telnet()
t.open('127.0.0.1','9051')
def burst(inp):
 for e in inp.split('\n'):
  prep=e
  print prep
  t.write (e+'\n')
  ds=t.expect([re.compile('\n')])
  print ds[2].strip()
#login for tor control protocol
burstcommand=""
burst(burstcommand)
if len(sys.argv)>1:
 f=open(sys.argv[1],'r')
 good=f.readline().split(',')
 others=f.readline().split(',')
 good=filter(lambda x:x not in others,good)
 exclude=f.readline().split(',')
 others=filter(lambda x:x not in exclude,others);
 assert(len(good)>0)
 assert(len(others)>0)
 f.close()
else: raise Exception("list needed")
import random

cont=True
while cont:
 for j in range(10):
  if cont:
   s=list()
   if len(others)>1:
xx=good[random.randint(0,len(good)-1)]
s.append(xx)
s.append(others.pop(random.randint(0,len(others)-1)))
   else:
print 'others insufficient'
cont=False
break
   if cont==True:
#print "extendcircuit 0", ",".join(s)
burst("extendcircuit 0 {0}".format(",".join(s)))
  else:
   break
 print "="
 time.sleep(60)
t.close()
--
Regards.


--
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: deadlock with busy waiting on sigfe

[jojelino]

On 2013-03-11 PM 11:36, Christopher Faylor wrote:

A "proper bug report" would at least include what you were actually doing
to trigger this problem.

I was trying to CTRL+C cygwin python process that is executing some 
operation and fell asleep for 60 seconds repeatedly. I'm pretty sure 
that the process was sleeping as i tried interrupt it.



Are you sure that there are only two threads executing here?  It seems like
this is a symptom of another thread holding the lock.

It's unlikely the case because there was two thread running when 
livelock observed.

cgf


Thread 2 (Thread 7596.0x104):
#0  0x7c96845c in ntdll!KiFastSystemCallRet ()
from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1  0x7c9678c9 in ntdll!ZwSetInformationThread ()
from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2  0x7c8324f9 in SetThreadPriority ()
from /cygdrive/c/WINDOWS/system32/kernel32.dll
#3  0x6108790d in yield ()
 at
/netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/miscfuncs.cc:253
#4  0x610d7354 in _cygtls::lock() () from /usr/bin/cygwin1.dll
#5  0x6103096e in sigpacket::setup_handler (this=0x6aac34,
 handler=0x6102fe00 , siga=...,
tls=0x22ce64)
 at
/netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/exceptions.cc:796
#6  0x610318ff in sigpacket::process (this=0x6aac34)
 at
/netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/exceptions.cc:1245
---Type  to continue, or q  to quit---
#7  0x610dd74c in wait_sig ()
 at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/sigproc.cc:1389
#8  0x61003ea5 in cygthread::callfunc (this=0x6118b420 ,
 issimplestub=)
 at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/cygthread.cc:51
#9  0x6100442f in cygthread::stub (arg=0x6118b420 )
 at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/cygthread.cc:93
#10 0x6100537d in _cygtls::call2 (this=,
 func=0x610043e0 , arg=0x6118b420 ,
 buf=0x6100551b <_cygtls::call(unsigned long (*)(void*, void*),
void*)+91>)
 at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/cygtls.cc:99
#11 0x006affb8 in ?? ()
#12 0x7c82484f in KERNEL32!GetModuleHandleA ()
from /cygdrive/c/WINDOWS/system32/kernel32.dll
#13 0x in ?? ()

Thread 1 (Thread 7596.0x190):
#0  0x7c96845c in ntdll!KiFastSystemCallRet ()
from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1  0x7c9678c9 in ntdll!ZwSetInformationThread ()
from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2  0x7c8324f9 in SetThreadPriority ()
from /cygdrive/c/WINDOWS/system32/kernel32.dll
#3  0x610878cb in yield ()
---Type  to continue, or q  to quit---
 at
/netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/miscfuncs.cc:244
#4  0x610d7354 in _cygtls::lock() () from /usr/bin/cygwin1.dll
#5  0x61031297 in _cygtls::call_signal_handler (
 this=0x610d7354 <_cygtls::lock()+23>)
 at
/netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/exceptions.cc:1265
#6  0x61007689 in _cygwin_exit_return ()
 at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/dcrt0.cc:1012
#7  0x6100537d in _cygtls::call2 (this=,
 func=0x61006c50 , arg=0x0,
 buf=0x6100551b <_cygtls::call(unsigned long (*)(void*, void*),
void*)+91>)
 at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/cygtls.cc:99
#8  0x0022ff78 in ?? ()
#9  0x004011d2 in ?? ()
#10 0x00401015 in ?? ()
#11 0x7c82f243 in ProcessIdToSessionId ()
from /cygdrive/c/WINDOWS/system32/kernel32.dll

--
Regards.


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







--
Regards.


--
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: deadlock with busy waiting on sigfe

[jojelino]

On 2013-01-20 PM 3:54, Christopher Faylor wrote:

On Sun, Jan 20, 2013 at 02:23:23PM +0900, jojelino wrote:
Once again: don't care about your backtraces.  Submit a proper bug report.

cgf

And found another livelock with CYGWIN_NT-5.2 F8G6S6D42HGDY4 
1.7.18s(0.263/5/3) 20130309 21:57:01 i686 Cygwin provided in 
http://cygwin.org/snapshots/cygwin1-20130309.dll.bz2
I can't submit proper bug report. it just hangs during CTRL+C for 
arbitrary cygwin executable and there is nothing i can do except dumping 
backtrace. If you don't care about it, it's ok to ignore this. please 
pass by.

Thread 2 (Thread 7596.0x104):
#0  0x7c96845c in ntdll!KiFastSystemCallRet ()
   from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1  0x7c9678c9 in ntdll!ZwSetInformationThread ()
   from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2  0x7c8324f9 in SetThreadPriority ()
   from /cygdrive/c/WINDOWS/system32/kernel32.dll
#3  0x6108790d in yield ()
at 
/netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/miscfuncs.cc:253

#4  0x610d7354 in _cygtls::lock() () from /usr/bin/cygwin1.dll
#5  0x6103096e in sigpacket::setup_handler (this=0x6aac34,
handler=0x6102fe00 , siga=..., 
tls=0x22ce64)
at 
/netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/exceptions.cc:796

#6  0x610318ff in sigpacket::process (this=0x6aac34)
at 
/netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/exceptions.cc:1245

---Type  to continue, or q  to quit---
#7  0x610dd74c in wait_sig ()
at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/sigproc.cc:1389
#8  0x61003ea5 in cygthread::callfunc (this=0x6118b420 ,
issimplestub=)
at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/cygthread.cc:51
#9  0x6100442f in cygthread::stub (arg=0x6118b420 )
at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/cygthread.cc:93
#10 0x6100537d in _cygtls::call2 (this=,
func=0x610043e0 , arg=0x6118b420 ,
buf=0x6100551b <_cygtls::call(unsigned long (*)(void*, void*), 
void*)+91>)

at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/cygtls.cc:99
#11 0x006affb8 in ?? ()
#12 0x7c82484f in KERNEL32!GetModuleHandleA ()
   from /cygdrive/c/WINDOWS/system32/kernel32.dll
#13 0x in ?? ()

Thread 1 (Thread 7596.0x190):
#0  0x7c96845c in ntdll!KiFastSystemCallRet ()
   from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1  0x7c9678c9 in ntdll!ZwSetInformationThread ()
   from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2  0x7c8324f9 in SetThreadPriority ()
   from /cygdrive/c/WINDOWS/system32/kernel32.dll
#3  0x610878cb in yield ()
---Type  to continue, or q  to quit---
at 
/netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/miscfuncs.cc:244

#4  0x610d7354 in _cygtls::lock() () from /usr/bin/cygwin1.dll
#5  0x61031297 in _cygtls::call_signal_handler (
this=0x610d7354 <_cygtls::lock()+23>)
at 
/netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/exceptions.cc:1265

#6  0x61007689 in _cygwin_exit_return ()
at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/dcrt0.cc:1012
#7  0x6100537d in _cygtls::call2 (this=,
func=0x61006c50 , arg=0x0,
buf=0x6100551b <_cygtls::call(unsigned long (*)(void*, void*), 
void*)+91>)

at /netrel/src/cygwin-snapshot-20130309-1/winsup/cygwin/cygtls.cc:99
#8  0x0022ff78 in ?? ()
#9  0x004011d2 in ?? ()
#10 0x00401015 in ?? ()
#11 0x7c82f243 in ProcessIdToSessionId ()
   from /cygdrive/c/WINDOWS/system32/kernel32.dll

--
Regards.


--
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: wrong performance of malloc/free under multi-threading

[jojelino]

On 2013-02-26 PM 10:25, Corinna Vinschen wrote:


This is Cygwin only.


Corinna

cygwin malloc is not reentrant according to malloc_wrapper.cc so let's 
not expect performance like linux or native windows. until someone have 
plenty of time to resolve this issue.

--
Regards.


--
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: deadlock with busy waiting on sigfe

[jojelino]

On 2013-01-16 AM 11:14, Christopher Faylor wrote:

On Tue, Jan 15, 2013 at 08:46:46PM -0500, Christopher Faylor wrote:
Sorry, the backtraces were actually useful because they show that you
are apparently running cygwin-snapshot-20130107.  Apparently you haven't
been watching the discussion about this issue in the Cygwin list.  The
problem of a Cygwin process hanging after a single CTRL-C should be
fixed in later snapshots although there is another reported CTRL-C
issue.

cgf

now i found hang where the argument of program was sed 
s/^\(.*\)-\([^-]*-[^-]*\)$/\2/ with newer cygwin snapshot.



(gdb) thread apply all bt

Thread 4 (Thread 12972.0x382c):
#0  0x7c95a22a in ntdll!DbgBreakPoint ()
   from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1  0x7c97fc68 in ntdll!DbgUiRemoteBreakin ()
   from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2  0x0005 in ?? ()
#3  0x0001 in ?? ()
#4  0x003effd0 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 2 (Thread 12972.0x32c8):
#0  0x7c96845c in ntdll!KiFastSystemCallRet ()
   from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1  0x7c9678c9 in ntdll!ZwSetInformationThread ()
   from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2  0x7c8324f9 in SetThreadPriority ()
   from /cygdrive/c/WINDOWS/system32/kernel32.dll
#3  0x6108760b in yield ()
at 
/netrel/src/cygwin-snapshot-20130118-1/winsup/cygwin/miscfuncs.cc:244

#4  0x610d6ee4 in _cygtls::lock() () from /usr/bin/cygwin1.dll
#5  0x6103035e in sigpacket::setup_handler (this=0x6cac34,
handler=0x6102fe30 , siga=..., 
tls=0x22ce64)

---Type  to continue, or q  to quit---
at 
/netrel/src/cygwin-snapshot-20130118-1/winsup/cygwin/exceptions.cc:796

#6  0x61031a48 in sigpacket::process (this=0x6cac34)
at 
/netrel/src/cygwin-snapshot-20130118-1/winsup/cygwin/exceptions.cc:1274

#7  0x610dd2dc in wait_sig ()
at /netrel/src/cygwin-snapshot-20130118-1/winsup/cygwin/sigproc.cc:1389
#8  0x61003ea5 in cygthread::callfunc (this=0x6118b400 ,
issimplestub=)
at /netrel/src/cygwin-snapshot-20130118-1/winsup/cygwin/cygthread.cc:51
#9  0x6100442f in cygthread::stub (arg=0x6118b400 )
at /netrel/src/cygwin-snapshot-20130118-1/winsup/cygwin/cygthread.cc:93
#10 0x6100538d in _cygtls::call2 (this=,
func=0x610043e0 <_ZN9cygthread4stubEPv@4>, arg=0x6118b400 ,
buf=0x6100551b <_cygtls::call(unsigned long (*)(void*, void*), 
void*)+91>)

at /netrel/src/cygwin-snapshot-20130118-1/winsup/cygwin/cygtls.cc:99
#11 0x006cffb8 in ?? ()
#12 0x7c82484f in KERNEL32!GetModuleHandleA ()
   from /cygdrive/c/WINDOWS/system32/kernel32.dll
#13 0x in ?? ()

Thread 1 (Thread 12972.0x2f38):
#0  0x7c96845c in ntdll!KiFastSystemCallRet ()
   from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1  0x7c9678c9 in ntdll!ZwSetInformationThread ()
---Type  to continue, or q  to quit---
   from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2  0x7c8324f9 in SetThreadPriority ()
   from /cygdrive/c/WINDOWS/system32/kernel32.dll
#3  0x6108764d in yield ()
at 
/netrel/src/cygwin-snapshot-20130118-1/winsup/cygwin/miscfuncs.cc:253

#4  0x610d6dcc in _sigfe () from /usr/bin/cygwin1.dll
#5  0x61083a40 in mallinfo ()
at 
/netrel/src/cygwin-snapshot-20130118-1/winsup/cygwin/malloc_wrapper.cc:2

6
#6  0x6123e9a0 in saved_categories () from /usr/bin/cygwin1.dll
#7  0x in ?? ()
(gdb)

(gdb) x 7ffdd000+4
0x7ffdd004: 0x0023
(gdb) x ((_cygtls*)(0x0023-319c))->stackptr
0x22da30:   0x61083ac9
(gdb) i line *0x61083ac9
Line 290 of 
"/netrel/src/cygwin-snapshot-20130118-1/winsup/cygwin/malloc_wrapper

.cc" starts at address 0x61083ac9 
   and ends at 0x61083ad3 .

It seems that malloc_init called sigfe-annotated malloc or free during 
wait_sig thread tried to process exit signal.



--
Regards.


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

deadlock with busy waiting on sigfe

[jojelino]

Caused by executing following command and ctrl+c to interrupt in bash shell.
sh -c "cd /tmp/openjpeg/src/bin/jp2 && /usr/bin/i686-pc-mingw32-gcc.exe 
 -DOPJ_EXPORTS -ffast-math -O3 -DNDEBUG 
@CMakeFiles/opj_compress.dir/includes_C.rsp   -o 
CMakeFiles/opj_compress.dir/convert.c.obj   -c 
/tmp/openjpeg/src/bin/jp2/convert.c"


SleepEx is being spammed across threads. some thread got tls lock but 
didn't released it.

how can i fix the problem?
(gdb) thread apply all bt
Thread 3 (Thread 8576.0x1b30):
#0  0x571ec771 in filename_completion_function ()
   from /usr/bin/cygreadline7.dll
#1  0x7c958f81 in ntdll!LdrShutdownThread ()
   from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2  0x571ec3c0 in filename_completion_function ()
   from /usr/bin/cygreadline7.dll
#3  0x7c97fc9b in ntdll!RtlExitUserThread ()
   from /cygdrive/c/WINDOWS/system32/ntdll.dll
#4  0x7c97fc73 in ntdll!DbgUiRemoteBreakin ()
   from /cygdrive/c/WINDOWS/system32/ntdll.dll
#5  0x in ?? ()

Thread 2 (Thread 8576.0xe38):
#0  0x7c801e8c in SleepEx () from /cygdrive/c/WINDOWS/system32/kernel32.dll
#1  0x610873f2 in yield ()
at 
/netrel/src/cygwin-snapshot-20130107-1/winsup/cygwin/miscfuncs.cc:251

#2  0x610d6da4 in _cygtls::lock() () from /usr/bin/cygwin1.dll
#3  0x6103035e in sigpacket::setup_handler (this=0xc3ac34,
handler=0x6102fdb0 , siga=..., 
tls=0x22ce64)
at 
/netrel/src/cygwin-snapshot-20130107-1/winsup/cygwin/exceptions.cc:797

#4  0x610319bb in sigpacket::process (this=0xc3ac34)
at 
/netrel/src/cygwin-snapshot-20130107-1/winsup/cygwin/exceptions.cc:1278

---Type  to continue, or q  to quit---
#5  0x610dd38c in wait_sig ()
at /netrel/src/cygwin-snapshot-20130107-1/winsup/cygwin/sigproc.cc:1415
#6  0x61003ea5 in cygthread::callfunc (this=0x6118b400 ,
issimplestub=)
at /netrel/src/cygwin-snapshot-20130107-1/winsup/cygwin/cygthread.cc:51
#7  0x6100442f in cygthread::stub (arg=0x6118b400 )
at /netrel/src/cygwin-snapshot-20130107-1/winsup/cygwin/cygthread.cc:93
#8  0x6100538d in _cygtls::call2 (this=,
func=0x610043e0 <_ZN9cygthread4stubEPv@4>, arg=0x6118b400 ,
buf=0x6100551b <_cygtls::call(unsigned long (*)(void*, void*), 
void*)+91>)

at /netrel/src/cygwin-snapshot-20130107-1/winsup/cygwin/cygtls.cc:99
#9  0x00c3ffb8 in ?? ()
#10 0x7c82484f in KERNEL32!GetModuleHandleA ()
   from /cygdrive/c/WINDOWS/system32/kernel32.dll
#11 0x in ?? ()

Thread 1 (Thread 8576.0x27b8):
#0  0x7c801e8d in SleepEx () from /cygdrive/c/WINDOWS/system32/kernel32.dll
#1  0x610873f2 in yield ()
at 
/netrel/src/cygwin-snapshot-20130107-1/winsup/cygwin/miscfuncs.cc:251

#2  0x610d6c8c in _sigfe () from /usr/bin/cygwin1.dll
#3  0x61103990 in pthread_kill ()
at /netrel/src/cygwin-snapshot-20130107-1/winsup/cygwin/thread.cc:3024
#4  0x610075fa in _cygwin_exit_return ()
---Type  to continue, or q  to quit---
at /netrel/src/cygwin-snapshot-20130107-1/winsup/cygwin/dcrt0.cc:978
#5  0x6100538d in _cygtls::call2 (this=,
func=0x61006bf0 , arg=0x0,
buf=0x6100551b <_cygtls::call(unsigned long (*)(void*, void*), 
void*)+91>)

at /netrel/src/cygwin-snapshot-20130107-1/winsup/cygwin/cygtls.cc:99
#6  0x0022ff78 in ?? ()
#7  0x00465672 in ?? ()
#8  0x00401033 in ?? ()
#9  0x7c82f243 in ProcessIdToSessionId ()
   from /cygdrive/c/WINDOWS/system32/kernel32.dll
#10 0x in ?? ()
--
Regards.


--
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: bash very slow in cygwin 1.7.16-1 Win7/64 bit

[jojelino]

On 2012-10-01 AM 5:43, Adam Rosi-Kessel wrote:

22   10401 [main] ls 24012 cygheap_user::ontherange: Set HOME (from
/etc/passwd) to /cygdrive/c/0/cygwin_home
   100   10501 [main] ls 24012 normalize_posix_path: src
/cygdrive/c/0/cygwin_home
40   10541 [main] ls 24012 normalize_posix_path:
/cygdrive/c/0/cygwin_home = normalize_posix_path
(/cygdrive/c/0/cygwin_home)
31   10572 [main] ls 24012 mount_info::conv_to_win32_path:
conv_to_win32_path (/cygdrive/c/0/cygwin_home)
42   10614 [main] ls 24012 mount_info::cygdrive_win32_path: src
'/cygdrive/c/0/cygwin_home', dst 'C:\0\cygwin_home'
38   10652 [main] ls 24012 set_flags: flags: binary (0x2)
36   10688 [main] ls 24012 mount_info::conv_to_win32_path: src_path
/cygdrive/c/0/cygwin_home, dst C:\0\cygwin_home, flags 0x4022, rc 0
   303   10991 [main] ls 24012 symlink_info::check: 0x0 = NtCreateFile
(\??\C:\0\cygwin_home)
87   11078 [main] ls 24012 mount_info::conv_to_posix_path:
conv_to_posix_path (c:\users\avk\SkyDrive\0\cygwin_home, no-keep-rel,
no-add-slash)
48   11126 [main] ls 24012 normalize_win32_path:
C:\users\avk\SkyDrive\0\cygwin_home = normalize_win32_path
(c:\users\avk\SkyDrive\0\cygwin_home)
24   11150 [main] ls 24012 mount_info::conv_to_posix_path:
/cygdrive/c/users/avk/SkyDrive/0/cygwin_home = conv_to_posix_path
(c:\users\avk\SkyDrive\0\cygwin_home)
51   11201 [main] ls 24012 symlink_info::check: 44 =
symlink.check(C:\0\cygwin_home, 0x2890F8) (0x4804023)
35   11236 [main] ls 24012 path_conv::check:
this->path(C:\0\cygwin_home), has_acls(1)
64   11300 [main] ls 24012 win_env::add_cache: posix
/cygdrive/c/0/cygwin_home
27   11327 [main] ls 24012 win_env::add_cache: native
HOME=C:\0\cygwin_home
46   11373 [main] ls 24012 normalize_posix_path: src
/cygdrive/c/0/cygwin_home
24   11397 [main] ls 24012 normalize_posix_path:
/cygdrive/c/0/cygwin_home = normalize_posix_path
(/cygdrive/c/0/cygwin_home)
25   11422 [main] ls 24012 mount_info::conv_to_win32_path:
conv_to_win32_path (/cygdrive/c/0/cygwin_home)
25   11447 [main] ls 24012 mount_info::cygdrive_win32_path: src
'/cygdrive/c/0/cygwin_home', dst 'C:\0\cygwin_home'
25   11472 [main] ls 24012 set_flags: flags: binary (0x2)
24   11496 [main] ls 24012 mount_info::conv_to_win32_path: src_path
/cygdrive/c/0/cygwin_home, dst C:\0\cygwin_home, flags 0x4022, rc 0
   281   11777 [main] ls 24012 symlink_info::check: 0x0 = NtCreateFile
(\??\C:\0\cygwin_home)
86   11863 [main] ls 24012 mount_info::conv_to_posix_path:
conv_to_posix_path (c:\users\avk\SkyDrive\0\cygwin_home, no-keep-rel,
no-add-slash)
37   11900 [main] ls 24012 normalize_win32_path:
C:\users\avk\SkyDrive\0\cygwin_home = normalize_win32_path
(c:\users\avk\SkyDrive\0\cygwin_home)
if the SkyDrive is trademark of M$ and if it needs network connection to 
remote server, it would piss you off like you have been experienced.
If it is the case, please stop using *Skydrive* mounted directory as 
home directory for specific user of cygwin unless your network 
connection is faster than your hard drive and it isn't that fast for 
sure according to your complaint.


--
Regards.


--
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: Please test snapshots

[jojelino]

Hi, I think i found a glitch in gmon.c

the testcase is following. and you can see it doesn't work.

int main()
{
char *proffile;
{
  char gmon_out[] = "gmon.out";
  proffile = gmon_out;
}
printf("%s\n",proffile);
}

---
$ ./a
a(▒"
Actually the above can't be expected to work. the above is exactly same 
case with gmon.c:206

-- Regards.


--
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: Built perl 5.6.2 on Cygwin 1.7.11, but get SIGABRT from resulting perl.exe

[jojelino]

On 2012-07-19 AM 2:45, Nicholas DiPiazza wrote:

Jojelino asked:

"What was the result of
 gdb --args perl
 symbol cygwin1.dll
 define btc
 bt
 c
 end
 # "Function "_sigfe_free" not defined." shouldn't be seen. if it does,
please use latest snapshot including debug symbol.
 b _sigfe_free
 disp *((unsigned*)$esp+1)
 r
 btc
 #and just press enter until sigabrt is hit. ?"

Here is the result.

$ gdb --args perl
GNU gdb (GDB) 7.3.50.20111026-cvs (cygwin-special)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-cygwin".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/windows7-vm/perl-5.6.2/perl...done.
(gdb) symbol cygwin1.dll
Load new symbol table from "/usr/bin/cygwin1.dll"? (y or n) y
Reading symbols from /usr/bin/cygwin1.dll...(no debugging symbols
found)...done.
(gdb) define btc
Type commands for definition of "btc".
End with a line saying just "end".

bt
c
end

(gdb) b _sigfe_free
Breakpoint 1 at 0x610d420a
(gdb) disp *((unsigned*)$esp+1)
(gdb) r
Starting program: /home/windows7-vm/perl-5.6.2/perl
[New Thread 2184.0xec0]
[New Thread 2184.0xef0]

Breakpoint 1, 0x610d420a in _sigfe_free ()
from /cygdrive/c/cygwin/bin/cygwin1.dll
1: *((unsigned*)$esp+1) = 2147483664
(gdb) btc
#0  0x610d420a in _sigfe_free () from /cygdrive/c/cygwin/bin/cygwin1.dll
#1  0x61082119 in malloc_init() () from /cygdrive/c/cygwin/bin/cygwin1.dll
#2  0x in ?? ()

Program received signal SIGABRT, Aborted.
0x7718f8b1 in ntdll!RtlUpdateClonedSRWLock ()
from /cygdrive/c/Windows/system32/ntdll.dll
1: *((unsigned*)$esp+1) = 1987840657
(gdb)
#0  0x7718f8b1 in ntdll!RtlUpdateClonedSRWLock ()
from /cygdrive/c/Windows/system32/ntdll.dll
#1  0x7718f8b1 in ntdll!RtlUpdateClonedSRWLock ()
from /cygdrive/c/Windows/system32/ntdll.dll
#2  0x767c0a91 in WaitForSingleObjectEx ()
from /cygdrive/c/Windows/syswow64/KERNELBASE.dll
#3  0x00a8 in ?? ()
#4  0x in ?? ()






Hello, Nicholas.
It seems that perl-5.6.2 supplies its own malloc, which is incompatible 
to cygwin.
and cygwin startfile crt0.o which is linked with your perl build accepts 
malloc of perl-5.6.2/malloc.c during its initialization, please fix your 
perl build not to override malloc.



--
Regards.


--
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: Built perl 5.6.2 on Cygwin 1.7.11, but get SIGABRT from resulting perl.exe

[jojelino]

On 2012-07-18 AM 4:55, Nicholas DiPiazza wrote:

Jojelino asked:

   "and then, what was the result of
   gdb --args perl
   b _sigfe_free if *((unsigned*)$esp+1)==0x2010 #which i am interested in 
to see what the backtrace was.
   disp *((unsigned*)$esp+1)
   r
   bt #when breakpoint is hit"


Here is the result:

$ gdb --args perl
GNU gdb (GDB) 7.3.50.20111026-cvs (cygwin-special)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-cygwin".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/windows7-vm/perl-5.6.2/perl...done.
(gdb) b _sigfe_free if *((unsigned*)$esp+1)==0x2010
Function "_sigfe_free" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y

Breakpoint 1 (_sigfe_free if *((unsigned*)$esp+1)==0x2010) pending.
(gdb) disp *((unsigned*)$esp+1)
(gdb) r
Starting program: /home/windows7-vm/perl-5.6.2/perl
[New Thread 2320.0xc08]
[New Thread 2320.0xdac]

Program received signal SIGABRT, Aborted.
0x7718f8b1 in ntdll!RtlUpdateClonedSRWLock ()
from /cygdrive/c/Windows/system32/ntdll.dll
1: *((unsigned*)$esp+1) = 1987840657
(gdb) bt
#0  0x7718f8b1 in ntdll!RtlUpdateClonedSRWLock ()
from /cygdrive/c/Windows/system32/ntdll.dll
#1  0x7718f8b1 in ntdll!RtlUpdateClonedSRWLock ()
from /cygdrive/c/Windows/system32/ntdll.dll
#2  0x767c0a91 in WaitForSingleObjectEx ()
from /cygdrive/c/Windows/syswow64/KERNELBASE.dll
#3  0x00a8 in ?? ()
#4  0x in ?? ()



I'm sorry, the breakpoint wasn't hit.  what was the result of
gdb --args perl
symbol cygwin1.dll
define btc
bt
c
end
# "Function "_sigfe_free" not defined." shouldn't be seen. if it does, 
please use latest snapshot including debug symbol.

b _sigfe_free
disp *((unsigned*)$esp+1)
r
btc
#and just press enter until sigabrt is hit.
--
Regards.


--
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: Built perl 5.6.2 on Cygwin 1.7.11, but get SIGABRT from resulting perl.exe

[jojelino]

On 2012-07-17 AM 4:52, Nicholas DiPiazza wrote:

Hi jojelino,

You asked:


what is result of
gdb --args perl
b abort
r
bt (when breakpoint is hit.)


Here it is:

nick@nick-PC ~/perl-5.6.2
$ gdb --args perl
GNU gdb (GDB) 7.3.50.20111026-cvs (cygwin-special)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-cygwin".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/nick/perl-5.6.2/perl...done.
(gdb) b abort
Function "abort" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y

Breakpoint 1 (abort) pending.
(gdb) r
Starting program: /home/nick/perl-5.6.2/perl
[New Thread 3916.0xe18]
[New Thread 3916.0xae4]

Breakpoint 1, abort ()
 at
/home/corinna/src/cygwin/cygwin-1.7.15/cygwin-1.7.15-1/src/cygwin-1.7.15/
 winsup/cygwin/signal.cc:374
374
/home/corinna/src/cygwin/cygwin-1.7.15/cygwin-1.7.15-1/src/cygwin-1.7.15
/winsup/cygwin/signal.cc: No such file or directory.
 in
/home/corinna/src/cygwin/cygwin-1.7.15/cygwin-1.7.15-1/src/cygwin-1.7
..15/winsup/cygwin/signal.cc
(gdb) bt
#0  abort ()
 at
/home/corinna/src/cygwin/cygwin-1.7.15/cygwin-1.7.15-1/src/cygwin-1.7.15/
 winsup/cygwin/signal.cc:374
#1  0x6110f305 in dlfree (mem=)
 at
/home/corinna/src/cygwin/cygwin-1.7.15/cygwin-1.7.15-1/src/cygwin-1.7.15/
 winsup/cygwin/malloc.cc:4242
#2  0x610831b0 in free (p=0x2010)
 at
/home/corinna/src/cygwin/cygwin-1.7.15/cygwin-1.7.15-1/src/cygwin-1.7.15/
 winsup/cygwin/malloc_wrapper.cc:49
#3  0x610d50f5 in _sigfe () from /cygdrive/c/cygwin/bin/cygwin1.dll
#4  0x in ?? ()
(gdb)

Let me know if you would like to see anything else.



and then, what was the result of
gdb --args perl
b _sigfe_free if *((unsigned*)$esp+1)==0x2010 #which i am interested 
in to see what the backtrace was.

disp *((unsigned*)$esp+1)
r
bt #when breakpoint is hit.
--
Regards.


--
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: Built perl 5.6.2 on Cygwin 1.7.11, but get SIGABRT from resulting perl.exe

[jojelino]

On 2012-07-17 AM 3:35, Nicholas DiPiazza wrote:

Hi Reini Urban,

Thanks for this and sorry for my delay in response. '

I tried switching to a 32-bit system before doing the build, rebaseall,
perlrebase, patchperl, and perlall. Each of these still result in the Abort
signal being thrown.

$ ldd perl.exe
 ntdll.dll => /cygdrive/c/Windows/SYSTEM32/ntdll.dll (0x771e)
 kernel32.dll => /cygdrive/c/Windows/system32/kernel32.dll
(0x75cf)
 KERNELBASE.dll => /cygdrive/c/Windows/system32/KERNELBASE.dll
(0x7556)
 libperl5_6_2.dll => /home/nick/perl-5.6.2/libperl5_6_2.dll
(0x6614)
 cygcrypt-0.dll => /usr/bin/cygcrypt-0.dll (0x681a)
 cygwin1.dll => /usr/bin/cygwin1.dll (0x6100)
 cyggcc_s-1.dll => /usr/bin/cyggcc_s-1.dll (0x6768)

Important note: The perl5.6.2 did not build on Cygwin without changing

static_ext =   lib/auto/Win32CORE/Win32CORE$(LIB_EXT)

to this

static_ext =

Is that why I am having the problem?

-Nicholas


Looks like a failing rebase on an incredibly low address 0xa7.
Try rebaseall.

And then maybe a
$ perlrebase 5.6.2
But it rather looks like a system dll. libz.dll maybe.
Note: The argument 5.6.2 to find your right executable suffix



From my experience only lib/File/Find.pm from a newer perl is required
(I  took 5.8.1), otherwise you not be able to installe other modules
because the are not found.



I usually install old stuff with App::perlall and/or Devel::PatchPerl
--
Reini Urban
http://cpanel.net/ ? http://www.perl-compiler.org/

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

References:
Built perl 5.6.2 on Cygwin 1.7.11, but get SIGABRT from resulting
perl.exe
From: Nicholas DiPiazza


-Original Message-
From: Nicholas DiPiazza [mailto:nicholas.dipiazza at gmail.com]
Sent: Thursday, June 21, 2012 12:46 PM
To: cygwin at cygwin.com
Subject: Built perl 5.6.2 on Cygwin 1.7.11, but get SIGABRT from resulting
perl.exe



From: Nicholas DiPiazza [mailto:nicholas.dipiazza at gmail.com]
Sent: Thursday, June 21, 2012 12:41 PM
To: cygwn at cygwin.com
Subject: Built perl 5.6.2 on Cygwin 1.7.11, but get SIGABRT from resulting
perl.exe

Dear Cygwin Users,

I'm getting a SIGABRT when running a perl 5.6.2 that i built on cygwin
1.7.11.

See ldd from a working perl 5.10 http://pastebin.com/ytjVYg4F versus my
broken perl 5.6.2 http://pastebin.com/YXZ29NG6.

I turned on -DDEBUGGING on the ./Configure script. Here is the gdb backtrace
I have:

http://paste.scsys.co.uk/201064

Are there libraries missing? What's going on here?

-Nicholas DiPiazza
Openlogic Support





what is result of
gdb --args perl
b abort
r
bt (when breakpoint is hit.)
?
and http://paste.scsys.co.uk/201064 didn't exist any longer
--
Regards.


--
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: Interpreting a gdb backtrace

[jojelino]

On 2012-05-19 AM 9:30, Ken Brown wrote:


I built emacs with -g -O0.  gdb had the symbol table at the start of the
debugging session.  It's just after the crash that everything is messed up.

Ken


Then, i suspect that some function is called with function pointer type 
with different calling convention from itself, eventually stack frame is 
broken and return address goes into wrong place.
if it is the case, there is nothing we can expect from gdb backtrace. 
but at least we can inspect esp register ?? for example, type following

x $esp
x $esp-4
x $esp-8
x $esp-c ...
or
x $esp-0x40(or greater than) and just enter until you get value which 
seems to be return address.
and you can know what the return address is supposed to be(if it isn't 
relocated but it is scarce.)
i hope you can find return address. then you can breakpoint the annoying 
procedure.

--
Regards.




--
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: Interpreting a gdb backtrace

[jojelino]

On 2012-05-19 AM 6:08, Ken Brown wrote:

I'm trying to debug an emacs crash and am having trouble getting a
useful backtrace after the crash.  Here's an example:

#0  0x00289c08 in ?? ()
No symbol table info available.
#1  0x007ba148 in _malloc_mutex ()
No symbol table info available.
#2  0x in ?? ()
No symbol table info available.

i think you should provide symbol file of emacs to gdb. if it was 
stripped, you had better to build emacs from source code with -g (at 
least gcc 4.5 for CFI that gdb need to backtrace the stack frame with ease).


--
Regards.




--
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: a netcat that supports -X and -x ?

[jojelino]

On 2012-04-28 AM 5:48, Marilo wrote:

When I google man nc, I see

http://linux.die.net/man/1/nc

I see  -X proxy_version   and  -x proxy_address[:port]

But cygwin's netcat doesn't include that.

Is it possible to get a copy of netcat for cygwin(or even for windows, or both) 
that includes that -x and -X?



You have to build from source.
http://packages.debian.org/squeeze/netcat-openbsd
--
Regards.




--
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: Cygwin passes through null writes to other software when redirecting standard input/output (i.e. piping)

[jojelino]

On 2012-04-27 AM 9:17, Christopher Faylor wrote:

There's no way that Cygwin could know to "skip" a call to WriteFile().
Cygwin doesn't interpose itself in the middle of a pipe.  That would be
truly disastrous.  If it somehow looked at every pipe read/write rather
than just allowing I/O to flow from one end to the other, the mailing
list would be even more filled with people complaining that Cygwin is
slow.

Maybe i can measure how much it slowed down after applying the 
workaround of unworkable runtime of some non-free software.

--
Regards.


--
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: 1.7.13: pthreads crash on W7/W2008 WoW64

[jojelino]

On 2012-04-19 PM 11:47, Makarius wrote:

   I've tried everything I can think of and I really don't know what is
   going on.  I suspect that it is a combination of things that is
   confusing Cygwin. It looks as though it is segfaulting inside some code
   that Cygwin is using to produce a message but I can't tell what that
   message is or why it's producing it.  It could be that some Cygwin table
   has reached its limit.

Does the backtrace make any sense to any Cygwin pthreads experts out there?


The crash can be reproduced in the full application only, see current
download via
http://www4.in.tum.de/~wenzelm/test/website_18-Apr-2012/download.html in
the Cygwin section.  After unpacking the bulky
Isabelle_18-Apr-2012_bundle_x86-cygwin.tar.gz one needs to run the whole
thing like this:

   $ gdb contrib/polyml-5.4.1/x86-cygwin/poly.exe poly.exe.core
   (gdb) thread all apply bt

The output of this is included as attachment "bt" here.


Is it Poly/ML doing bad things with Cygwin pthreads, or a genuine Cygwin
problem introduced in recent pthreads renovations?


seems former. please get to poly/ml to fix the problem.

Any clues?



i done following by gdb --pid=(the pid of poly.exe)

$ gdb --pid=5360
GNU gdb (GDB) 7.4.50.20120202-cvs
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-cygwin".
For bug reporting instructions, please see:
.

warning: the current range check setting does not match the language.


warning: the current type check setting does not match the language.

Whether backtraces should continue past the entry point of a program is off.
Attaching to process 5360
[New Thread 5360.0x166c]
[New Thread 5360.0x12fc]
[New Thread 5360.0xbdc]
[New Thread 5360.0xbe0]
[New Thread 5360.0x142c]
[New Thread 5360.0x484]
[New Thread 5360.0x1188]
[New Thread 5360.0x11b4]
[New Thread 5360.0x10b4]
[New Thread 5360.0x1688]
[New Thread 5360.0xda0]
Reading symbols from 
/tmp/Isabelle_18-Apr-2012/contrib/polyml-5.4.1/x86-cygwin/poly.exe...(no 
debugging symbols found)...done.

(gdb) c
Continuing.
[New Thread 5360.0x924]
[New Thread 5360.0xda8]
[New Thread 5360.0x1148]
[New Thread 5360.0x1618]
[New Thread 5360.0x1e4]
[New Thread 5360.0x82c]
[New Thread 5360.0xe0c]
[New Thread 5360.0x148c]
[New Thread 5360.0x11d8]
[New Thread 5360.0x144c]
[New Thread 5360.0xdb8]
[New Thread 5360.0xf98]
[New Thread 5360.0x16d0]
[New Thread 5360.0x152c]
[New Thread 5360.0x1384]
[New Thread 5360.0x11c4]
[New Thread 5360.0xb6c]
[New Thread 5360.0xc8c]
[New Thread 5360.0x7dc]
[New Thread 5360.0x1038]
[New Thread 5360.0x2d4]
[New Thread 5360.0x1344]
[New Thread 5360.0xc4]
[New Thread 5360.0x17c0]
[New Thread 5360.0x16ac]
[New Thread 5360.0x1630]
[New Thread 5360.0x4e0]
[New Thread 5360.0xf7c]
[New Thread 5360.0xa00]
[New Thread 5360.0xa78]
[New Thread 5360.0x140]
[New Thread 5360.0x77c]
[New Thread 5360.0x118c]
[New Thread 5360.0x554]
[New Thread 5360.0xec0]
[New Thread 5360.0x1194]
[New Thread 5360.0xadc]
[New Thread 5360.0x10e8]
[New Thread 5360.0xd24]
[New Thread 5360.0x140c]
[New Thread 5360.0x105c]
[New Thread 5360.0x17dc]
[New Thread 5360.0x173c]
[New Thread 5360.0x7d4]
[New Thread 5360.0x488]
[New Thread 5360.0x11f8]
[New Thread 5360.0x890]
[New Thread 5360.0x106c]
[New Thread 5360.0x16c0]
[New Thread 5360.0x200]
[New Thread 5360.0xa60]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 5360.0x166c]
0x6680187b in ProcessMarkPointers::DoScanAddressAt(PolyWord*, bool) ()
   from 
/tmp/Isabelle_18-Apr-2012/contrib/polyml-5.4.1/x86-cygwin/cygpolyml-3.dll

(gdb) thread apply all bt
Thread 62 (Thread 5360.0xa60):
#0  0x7c96845c in ntdll!LdrAlternateResourcesEnabled ()
   from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1  0x7c967b69 in ntdll!ZwWaitForMultipleObjects32 ()
   from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2  0x7c82201c in WaitForMultipleObjectsEx ()
   from /cygdrive/c/WINDOWS/system32/kernel32.dll
warning: (Internal error: pc 0x2 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x2 in read in psymtab, but not in symtab.)

#3  0x0003 in ?? ()
warning: (Internal error: pc 0x2 in read in psymtab, but not in symtab.)

#4  0x7dcdc900 in ?? ()
#5  0x7c822fae in WaitForMultipleObjects ()
   from /cygdrive/c/WINDOWS/system32/kernel32.dll
#6  0x610fc4d6 in cancelable_wait (object=, 
timeout=0x7dcdc900,

cancel_action=cw_no_cancel_self, sig_wait=cw_sig_eintr)
at /tmp/winsup/winsup/cygwin/thread.cc:962
#7  0x in ?? ()

Thread 61 (Thread 5360.0x200):
#0  0x7c96845c in ntdll!LdrAlternateResourcesEnabled ()
   from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1  0x7c967b69 in ntdll!ZwWaitForMultipleObjects32 ()
   from /cygdrive/c/WINDOWS/system32/ntdll.d

Re: Win2000 compatibility

[jojelino]

2012-04-13 AM 12:19, iggor 쓴 글:

Hello,

It appears that Cygwin SETUP.EXE at this time is uncompatible with
Windows 2000, since it uses function GetModuleHandleExA
which leads to error in searching entry point in kernel32.dll.
So, I cannot run setup at all, even get help with option.
AFAIK, this function is absent in all Win2k, not only my
SP4, build 2195.


you can fix the problem by building setup.exe from scratch.

before you build setup.exe, please checkout commits that used 
GetModuleHandleExA, and fix it by replacing with alternative api 
provided in win2k.

--
GetModuleHandleEx is known to be supported in minimum winxp (0x0501), 
according to 
http://msdn.microsoft.com/en-us/library/windows/desktop/ms683200(v=vs.85).aspx
by the way, in winbase.h, it is enabled with minimum of win2k. which 
should be fixed.

#if (_WIN32_WINNT >= 0x0500)
WINBASEAPI BOOL WINAPI GetModuleHandleExA(DWORD,LPCSTR,HMODULE*);
WINBASEAPI BOOL WINAPI GetModuleHandleExW(DWORD,LPCWSTR,HMODULE*);
#endif

--
Regards.




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

mintty crashed with stackdump

[jojelino]

mintty became unresponsible and it was unusual. so i quit it and got 
stackdump.
as i don't have debug symbol for cygwin 1.7.10(0.259/5/3) 2012-02-05 
12:36,  following stacktrace is attached without any consideration 
whether is relevant to cygwin1.dll or not.


Stack trace:
Frame Function  Args
0022BFC8  7C821C7D  (020C, EA60, 00A4, 0022C0C4)
0022C0E8  610D9519  (, 743C3609, 77DFC054, )
0022C1D8  610D69AE  (, 0022C220, 611E3C74, 611EBA88)
0022C238  610D6E7E  (610CC738, 200572D0, , 0006)
0022C2E8  610D6FD0  (16DC, 0006, 0022C34C, 004F)
0022C308  610D6FFC  (0006, 0022CE80, 2000, 2005F0B8)
0022C338  610D7285  (0050, 0022C3A4, 00402F05, 0022C3A8)
  18389 [sig] mintty 5852 exception::handle: Exception: 
STATUS_ACCESS_VIOLATION

Exception: STATUS_ACCESS_VIOLATION at eip=6102F523
eax=6110D505 ebx=0054 ecx=0050 edx=61187A60 esi=0022CE64 
edi=
ebp=0101C7D8 esp=0101C7D0 program=D:\cygwin\bin\mintty.exe, pid 5852, 
thread sig

cs=001B ds=0023 es=0023 fs=003B gs= ss=0023
Stack trace:
Frame Function  Args
0101C7D8  6102F523  (61187A60, 611C8DE7, 0022C3A8, )
0101C808  6102F61C  (0022BFB4, 0001, 0001, )
0101CBC8  610D8BD6  (0022CE80, 0006, 0101CC00, 0101CC64)
0101CC28  61030C9E  (0088, 0101CC64, 00A4, 0101CD0C)
0101CD28  610DA127  (61186360, , , )
0101CD68  61003985  (, , , )
End of stack trace
--
Regards.


--
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: [ANNOUNCEMENT] Updated: cygwin-1.7.10-1

[jojelino]

2012-02-07 PM 3:49, Daniel Colascione 쓴 글:

On 2/6/12 8:35 PM, jojelino wrote:

2012-02-06 AM 1:29, Corinna Vinschen 쓴 글:

Hi Cygwin friends and users,



C:\Documents and Settings\Administrator>base64 oso|base64 -d -
base64: write error: Bad file descriptor
base64: write error

C:\Documents and Settings\Administrator>uname -a
CYGWIN_NT-5.2 1.7.10s(0.259/5/3) 20120202 16:59:00 i686 Cygwin

please check this problem.


Worksforme after creating a file called "oso".


 (And if I don't have

such a file, the command fails in the expected way.)


sorry for confusion

rem make empty file
C:\>touch boa

C:\>base64 boa|base64 -d -
rem make non empty file
C:\>echo blahblah >oso

C:\>base64 boa|base64 -d -

C:\>base64 boa|base64 -d -

C:\>base64 oso|base64 -d -
blahblah

C:\>base64 oso|base64 -d -
base64: write error: Bad file descriptor
base64: write error

C:\>base64 oso|base64 -d -
base64: write error: Bad file descriptor
base64: write error

C:\>base64 oso|base64 -d -
base64: write error: Bad file descriptor
base64: write error

C:\>base64 oso|base64 -d -
base64: write error: Bad file descriptor
base64: write error

empty file always worked.
for non-empty file it does worked or not.
strace for base64 -d solved the write error. so i couldn't figure it out 
quite well.


--
Regards.


--
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: [ANNOUNCEMENT] Updated: cygwin-1.7.10-1

[jojelino]

2012-02-06 AM 1:29, Corinna Vinschen 쓴 글:

Hi Cygwin friends and users,



C:\Documents and Settings\Administrator>base64 oso|base64 -d -
base64: write error: Bad file descriptor
base64: write error

C:\Documents and Settings\Administrator>uname -a
CYGWIN_NT-5.2 1.7.10s(0.259/5/3) 20120202 16:59:00 i686 Cygwin

please check this problem.
--
Regards.


--
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: ctrl+c problem when non-cygwin process is invoked by cygwin-process.

[jojelino]

On 2011-12-06 PM 6:37, Corinna Vinschen wrote:

A lot of changes and fixes have been made in Cygwin since 1.7.9 has
been released, so we're looking forward to release Cygwin 1.7.10 soon.

Please test the latest developer snapshots at http://cygwin.com/snapshots/
which should have "Release Candidate" quality.


here is simple shell script attached.
i'm using 32-bit windows. and the attached doesn't invoke timeout of 
cygwin land.

. execute following line in non-cygwin process.(typically in cmd.exe)
sh ./test
. ctrl+c before *press any key to continue* disappear, and you are *jammed*
. whenever you ctrl+c while process hang, ctrlc handler thread would 
continue to be attached to child sh process.


-- here is strace log.
http://pastebin.com/dSVAXtsd
--
(gdb) x 7C8451C5
0x7c8451c5 : 0xfffc4d83
(gdb) x/i 7C8451C5
=> 0x7c8451c5 :
 orl$0x,-0x4(%ebp)
(gdb)
0x7c8451c9 :
 jmp0x7c845235 
(gdb)

Regards.


--
Regards.
#!/bin/sh
echo sleep for 3 second
$WINDIR/system32/timeout 3--
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: Performance issue in SFTP , CygWin Server

[jojelino]

On 2011-10-05 PM 10:41, BhavyaMadiri wrote:

We have not encountered any performance problems with downloading files
(same number and size ) from unix/linux systems using SFTP.

We suspect this performance issue to be related to Cygwin.

Any inputs on this is greatly appreciated.

if you do care performance problems, you can try cygwin.dll snapshot 
provided in cygwin.com.
and if you are not satisfied with that, you can also try doing roll-back 
libintl-8 to 0.17-11

--
Regards.


--
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: Relocation patch for cygwin

[jojelino]

On 2011-09-26 AM 9:50, Charles Wilson wrote:

Well, the libiconv distributed as an official cygwin package *SHOULD*
not have been built with --enable-relocation, so only a subset of the
"relocation" code *OUGHT* to be involved -- just enough for any calls to
relocate() to return the passed-in string IIRC.

However...it appears that I MAY have mistakenly uploaded the version I
built WITH relocation enabled (which I generally do for testing
purposes, just to make sure it still works).  I'll need to double check.

there is '-DENABLE_RELOCATABLE=1' in 
http://git.savannah.gnu.org/cgit/gettext.git/tree/gettext-runtime/intl/Makefile.in 
which cannot be affected by `--enable-relocation`. it would have been 
-DENABLE_RELOCATABLE=@RELOCATABLE@ i think.



--
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: Relocation patch for cygwin

[jojelino]

On 2011-09-24 AM 5:10, jojelino wrote:

The attached is report gprof produced when invoked *id* . as you can
see, format_process_maps consumes 70% of the lifetime(0.5s with
profiling overhead). this is reproducible whenever we do
open('/proc/self/maps').
the problem is, the cost is too expensive. gnulib should care about
cygwin do sacrifice performance for compatibility.
As a workaround, how about rebuild libintl without capacity of relocatable?
because in cygwin libintl is expected to place in /bin so there's no use
of relocatable.


A bug in profiling code was found and fixed. revised time consumption of 
format_process_maps is now 60%.

http://pastebin.com/yYh6fNbS for detailed gprof result.


--
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: Bogus dependencies in libtool .la files for libgtk2.0-devel-2.20.1-1, libpango1.0-devel-1.28.1-1

[jojelino]

On 2011-09-26 AM 1:00, Dave Korn wrote:

This problem comes from *executing libtool commands*


   If a problem arises from executing libtool commands, that usually means that
something the user did in Makefile.am has tricked automake into generating
incorrect libtool commands in the first place, rather than that an actual
libtool bug has just appeared.  (Libtool bugs are possible of course, but user
errors in automake scripts are more common.)

 cheers,
   DaveK




The problem is from pango/opentype/libharfbuzz.la
It has .cc source and recognized as needed c++ source file although it 
is c source. and cc source is compiled with --tag=CXX

we should teach libtool cc is c source file.
Regards


--
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: Bogus dependencies in libtool .la files for libgtk2.0-devel-2.20.1-1, libpango1.0-devel-1.28.1-1, libpango1.0-devel-1.28.1-1

[jojelino]

On 2011-09-26 AM 12:57, Dave Korn wrote:

   I think this is just libtool working normally; $postdeps is the current
dependencies for this particular invocation, and internally it's doing
something like "postdeps=${postdeps_${tag}}" so it's setting
postdeps=$postdeps_CXX in response to getting --tag=CXX on the command-line,
isn't it?  The underlying cause is more likely to be in the way that the
Makefile.am is setting the libtool control variables, which is probably an
issue for upstream.


On 25/09/2011 16:42, jojelino wrote:
The latter mail has detail(former one was cancelled but i was already 
late). the auto-generated libtool doesn't seem to clobber postdeps for 
tag specified. then postdeps would be latter one which should have been 
postdeps_CXX.




--
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: Bogus dependencies in libtool .la files for libgtk2.0-devel-2.20.1-1, libpango1.0-devel-1.28.1-1, libpango1.0-devel-1.28.1-1

[jojelino]

On 2011-09-25 PM 11:51, Dave Korn wrote:

before you can compile it from source, and that it might be worth backing up
the .la files just in case this -lstdc++ actually is required somewhere, but
I'd be happier if this could either be fixed in the distro, or if someone
could tell me why these libs think they need to link against libstdc++?

 cheers,
   DaveK




This problem comes from *executing libtool commands*
You can see in config.status of pango

$ cat config.status|grep postdeps
postdeps=''
postdeps_CXX='-lstdc++ -lmingwthrd -lmingw32 -lgcc_s -lgcc -lmoldname 
-lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingwthrd 
-lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt'


rm ./libtool
./config.status #we can see *executing libtool commands*. and libtool is 
auto-generated.

and now resulting libtool has ill-tagged postdeps variable

$ cat libtool|grep postdeps
postdeps=""
  # don't eliminate duplications in $postdeps and $predeps
  libs="$predeps $libs $compiler_lib_search_path $postdeps"
  # $postdeps and mark them as special (i.e., whose duplicates are
for pre_post_dep in $predeps $postdeps; do
  case " $predeps $postdeps " in
case " $predeps $postdeps $compiler_lib_search_path " in
  case " $predeps $postdeps " in
case " $predeps $postdeps " in
case " $predeps $postdeps " in
case " $predeps $postdeps " in
for i in $predeps $postdeps ; do
postdeps="-lstdc++ -lmingwthrd -lmingw32 -lgcc_s -lgcc -lmoldname 
-lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingwthrd 
-lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt"



Why we got postdeps instead of postdeps_CXX?

Regards.


--
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: Bogus dependencies in libtool .la files for libgtk2.0-devel-2.20.1-1, libpango1.0-devel-1.28.1-1, libpango1.0-devel-1.28.1-1

[jojelino]

On 2011-09-25 PM 11:51, Dave Korn wrote:

before you can compile it from source, and that it might be worth backing up
the .la files just in case this -lstdc++ actually is required somewhere, but
I'd be happier if this could either be fixed in the distro, or if someone
could tell me why these libs think they need to link against libstdc++?

 cheers,
   DaveK




lstdc++ is included in postdeps in libtool for some reason.

postdeps="-lstdc++ -lmingwthrd -lmingw32 -lgcc_s -lgcc -lmoldname 
-lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingwthrd 
-lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt"


this postdeps was introduced by
output_verbose_link_cmd='$CC -shared $CFLAGS -v conftest.$objext 2>&1 | 
$GREP -v "^Configured with:" | $GREP "\-L"'


but in config.status,
postdeps=''
postdeps_CXX='-lstdc++ -lmingwthrd -lmingw32 -lgcc_s -lgcc -lmoldname 
-lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingwthrd 
-lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt'

so it seems good.
therefore, this problem began from *executing libtool commands*.
the variable 'postdeps' is not tagged with "_CXX". resulting in 
wrong-generated libtool



--
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: Relocation patch for cygwin

[jojelino]

On 2011-09-24 PM 12:16, Christopher Faylor wrote:

Flat profile:


Please don't send this type of stuff here.  You've just spammed hundreds
of people with many kilobytes data that very few people care about.

cgf

I'm sorry about hundreds of spam mail. i keep myself from spamming by 
giving external link for many kilobytes.



--
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: compilation fails with Win32 API call

[jojelino]

On 2011-09-20 PM 6:12, Andrew Schulman wrote:

I'm trying to compile a program that calls the win32 function
SetThreadExecutionState, in kernel32.dll [1].  The link step fails:

$ gcc -c nosleep.c
$ gcc -o nosleep nosleep.o -lkernel32
nosleep.o:nosleep.c:(.text+0x1f): undefined reference to
`_SetThreadExecutionState'
nosleep.o:nosleep.c:(.text+0x5c): undefined reference to
`_SetThreadExecutionState'
collect2: ld returned 1 exit status

According to the FAQ [2], I shouldn't even have to include -lkernel32.

Can someone please tell me what I'm doing wrong?

Thanks,
Andrew.

[1] http://msdn.microsoft.com/en-us/library/aa373208(VS.85).aspx

here you are.
http://msdn.microsoft.com/en-us/library/aa383745.aspx

[2]
http://www.cygwin.com/faq/faq.programming.html#faq.programming.win32-api



please define WINVER so that you can get definition what you want
(gcc -E -DWINVER=0x500 - <
EOF
)|grep SetThreadExecution

now you can see SetThreadExecutionState is defined


--
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: debugging SIGSEV on pclose

[jojelino]

On 2011-09-08 PM 6:50, Marco atzeri wrote:

I am currently using debug version of cygwin-cvs, flkt-1.10 and octave;
but unfortunaltely the gdb backtrace is already corrupted/unclear at the
popen call, and I do not know if is real problem on a GDB issue :

---

you need to do b _sigfe_popen, because the generated sigfe.s doesn't 
emit any sort of dwarf 2 cfi, which gdb needed to backtrace.



--
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: debugging SIGSEV on pclose

[jojelino]

On 2011-09-05 PM 11:01, Marco atzeri wrote:

Hi jojelino,
gs is unlikely crashing as the fltk.png is correctly produced.
 From strace I know that octave crashes before gs complete its output.


i'm sorry. mine was not the case.
and after some digging, it is found that fd[6] is *closed* before pclose.

warning: print.m: epstool binary is not available.
Some output formats are not available.
Hardware watchpoint 3: cygheap->fdtab.fds[6]

Old value = (fhandler_base *) 0x0
New value = (fhandler_pipe *) 0x612dbb8c
_pipe (filedes=0x22b370, psize=0x1, mode=0x1)
at /tmp/winsup/winsup/cygwin/pipe.cc:382
382   filedes[0] = fdin;
(gdb) b _sigfe_fclose
Breakpoint 6 at 0x610f080b
(gdb) c
Continuing.
[New Thread 1684.0xf98]

Breakpoint 6, 0x610f080b in _sigfe_fclose ()
   from /cygdrive/d/cygwin/bin/cygwin1.dll
(gdb) bt
#0  0x610f080b in _sigfe_fclose () from /cygdrive/d/cygwin/bin/cygwin1.dll
#1  0x66f6a41f in 
cygoctinterp-0!_ZN13glps_renderer4drawERK15graphics_object ()

   from /cygdrive/d/cygwin/bin/cygoctinterp-0.dll
#2  0x6ec0ff2f in _init_fltk__-0!_ZN11OpenGL_fltk4drawEv ()
   from D:/cygwin/lib/octave/3.4.2/oct/i686-pc-cygwin/__init_fltk__.oct
#3  0x6dab19ef in cygfltk_gl-1!_ZN12Fl_Gl_Window5flushEv ()
   from /cygdrive/d/cygwin/bin/cygfltk_gl-1.1.dll
#4  0x6dae2a0f in cygfltk-1!_ZN2Fl5flushEv ()
   from /cygdrive/d/cygwin/bin/cygfltk-1.1.dll
#5  0x6dae2c28 in cygfltk-1!_ZN2Fl4waitEd ()
   from /cygdrive/d/cygwin/bin/cygfltk-1.1.dll
#6  0x6ec21272 in 
_init_fltk__-0!_ZNK21fltk_graphics_toolkit12print_figureERK15graphics_objectRKSsS4_bS4_ 
()

   from D:/cygwin/lib/octave/3.4.2/oct/i686-pc-cygwin/__init_fltk__.oct
#7  0x66ffc52b in cygoctinterp-0!_Z8FdrawnowRK17octave_value_listi ()
   from /cygdrive/d/cygwin/bin/cygoctinterp-0.dll
#8  0x67159266 in 
cygoctinterp-0!_ZN14octave_builtin17do_multi_index_opEiRK17octave_value_listPKSt4listI13octave_lvalueSaIS4_EE 
()

   from /cygdrive/d/cygwin/bin/cygoctinterp-0.dll
#9  0x67158397 in 
cygoctinterp-0!_ZN14octave_builtin7subsrefERKSsRKSt4listI17octave_value_listSaIS3_EEiPKS2_I13octave_lvalueSaIS8_EE 
()

   from /cygdrive/d/cygwin/bin/cygoctinterp-0.dll
#10 0x67159066 in 
cygoctinterp-0!_ZN14octave_builtin7subsrefERKSsRKSt4listI17oct---Type 
 to continue, or q  to quit---q

Quit
(gdb)

i think fltk have bad behavior which use fclose to close pipe fd, but it 
should have used pclose. so closing disposed fd yields sigsegv.

http://pubs.opengroup.org/onlinepubs/009695399/functions/pclose.html
we should inspect fltk's glps_renderer::draw(graphics_object const&) for 
this strange behavior.



--
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: debugging SIGSEV on pclose

[jojelino]

On 2011-09-05 PM 9:20, Marco atzeri wrote:

command=0x207e969c "/usr/bin/gs -dQUIET -dNOPAUSE -dBATCH -dSAFER
-sDEVICE=png16m -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -r150x150
-dEPSCrop -sOutputFile=fltk.png -", in_type=0x1a45b18 "w")
at /pub/cygwin/cvs/src_new/winsup/cygwin/syscalls.cc:3920
3920 {
as far as i know, -dTextAlphaBits=4 -dGraphicsAlphaBits=4 make gs crash. 
because if textalphabits is used, apple-patented font hinting is 
needed.(although freetype library implemented alternative hinting, it 
doesn't migrated to gs.) so gs calls THROW_PATENTED which uses 
longjmp(yet i can't make sure why it crashed instead of showing error 
message), there is bug report regarding to this issue(but not for this 
sigsegv). 
http://www.ghostscript.com/pipermail/gs-bugs/2009-November/010447.html

i think it would be okay if you remove textalphabits when invoking gs


--
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: TinyXML problem

[jojelino]

On 2011-08-25 AM 2:59, Gery . wrote:

g++ -DHAVE_CONFIG_H -I. -I../../source/headers -I../../source/headers/geos 
-I../../source/headers -I../../source/io/tinyxml -DTIXML_USE_STL-g -O2 
-DGEOS_INLINE  -pedantic -Wall -ansi -Wno-long-long  -ffloat-store -MT 
tinyxml.o -MD -MP -MF .deps/tinyxml.Tpo -c -o tinyxml.o `test -f 
'tinyxml/tinyxml.cpp' || echo './'`tinyxml/tinyxml.cpp


#!/usr/bin/bash
cd /usr/local/geos-3.2.2/
rm libtool
mv config.status config.status.old
sed -e "s/-ansi//g" config.status.old > config.status
./config.status
#and is it work now?


--
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: _mcleanup is called twice in forkee!

[jojelino]

On 2011-08-22 PM 6:27, jojelino wrote:

When a program is compiled with -pg, it causes invocation of _monstartup
and it calls atexit, the problem is, _mcleanup is called twice in forkee!

oh it was wrong. _monstartup is not called twice


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

_mcleanup is called twice in forkee!

[jojelino]

When a program is compiled with -pg, it causes invocation of _monstartup 
and it calls atexit, the problem is, _mcleanup is called twice in forkee!

That's because of _GLOBAL_REENT is copied when a process is forked.
Then we have two _mcleanup. (_monstartup is with __constructor__ 
attribute.) and this is not we wanted.
the same thing can be applied to any atexit call in cygwin which doesn't 
cares about forkee.



--
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: 1.7.10s 20110729 - problem listing services in /proc

[jojelino]

Starting program: /usr/bin/find 
/proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/services 
-maxdepth 1 -print

[New Thread 4648.0xd38]
warning: section .gnu_debuglink not found in 
/cygdrive/d/cygwin/bin/cygwin1.dbg

[New Thread 4648.0x16d8]

Breakpoint 9, fhandler_base::operator= (this=0x612cab6c, x=...)
at /tmp/winsup/winsup/cygwin/fhandler.cc:42
42  {
4: &x = (fhandler_pty_slave *) 0x612ca914
(gdb) c
Continuing.

Breakpoint 9, fhandler_base::operator= (this=0x612cab6c, x=...)
at /tmp/winsup/winsup/cygwin/fhandler.cc:42
42  {
4: &x = (fhandler_pty_slave *) 0x612ca914
(gdb) c
Continuing.

Breakpoint 9, fhandler_base::operator= (this=0x612cae5c, x=...)
at /tmp/winsup/winsup/cygwin/fhandler.cc:42
42  {
4: &x = (fhandler_pty_slave *) 0x612cab6c
(gdb) c
Continuing.

Breakpoint 9, fhandler_base::operator= (this=0x612cb424, x=...)
at /tmp/winsup/winsup/cygwin/fhandler.cc:42
42  {
4: &x = (fhandler_disk_file *) 0x612cb124
(gdb) c
Continuing.

Breakpoint 6, fhandler_registry::fhandler_registry (this=0x612cb124)
at /tmp/winsup/winsup/cygwin/fhandler_registry.cc:417
417   prefix_len = sizeof ("registry") - 1;
(gdb) disp this->value_name
8: this->value_name = 0x0
(gdb) c
Continuing.

Breakpoint 6, fhandler_registry::fhandler_registry (this=0x612cb124)
at /tmp/winsup/winsup/cygwin/fhandler_registry.cc:417
417   prefix_len = sizeof ("registry") - 1;
8: this->value_name = 0x0
(gdb)
Continuing.
/proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/services

Breakpoint 6, fhandler_registry::fhandler_registry (this=0x612cb124)
at /tmp/winsup/winsup/cygwin/fhandler_registry.cc:417
417   prefix_len = sizeof ("registry") - 1;
8: this->value_name = 0x0
(gdb)
Continuing.

Breakpoint 6, fhandler_registry::fhandler_registry (this=0x612cb124)
at /tmp/winsup/winsup/cygwin/fhandler_registry.cc:417
417   prefix_len = sizeof ("registry") - 1;
8: this->value_name = 0x0
(gdb)
Continuing.

Breakpoint 1, fhandler_registry::open (this=0x612cb124, flags=0x30c000,
mode=0x0) at /tmp/winsup/winsup/cygwin/fhandler_registry.cc:824
824   if (flags & O_APPEND)
(gdb) disp this->value_name
9: this->value_name = 0x612cb374 L"services"
(gdb) c
Continuing.

Breakpoint 6, fhandler_registry::fhandler_registry (this=0x612cba5c)
at /tmp/winsup/winsup/cygwin/fhandler_registry.cc:417
417   prefix_len = sizeof ("registry") - 1;
8: this->value_name = 0x0
(gdb)
Continuing.

Breakpoint 9, fhandler_base::operator= (this=0x612cba5c, x=...)
at /tmp/winsup/winsup/cygwin/fhandler.cc:42
42  {
4: &x = (fhandler_registry *) 0x612cb124
(gdb)
Continuing.

now 0x612cb124->value_name = 0x612cba5c->value_name 0x612cb374 L"services"
owner 0x612cba5c not freed value_name

Breakpoint 2, fhandler_registry::close (this=0x612cb124)
at /tmp/winsup/winsup/cygwin/fhandler_registry.cc:856
856   cfree (value_name);
(gdb) disp this->value_name
10: this->value_name = 0x612cb374 L"services"
(gdb) c
Continuing.

0x612cb124->value_name = 0x612cba5c->value_name 0x612cb374 L"services"
0x612cb124 freed value_name. but it was not owner.
owner 0x612cba5c not freed value_name

Breakpoint 3, fhandler_registry::close (this=0x612cb124)
at /tmp/winsup/winsup/cygwin/fhandler_registry.cc:860
860 }
10: this->value_name = 0x0
(gdb)
Continuing.

0x612cb124->value_name = 0
0x612cba5c->value_name 0x612cb374 L"services"
0x612cb124 freed value_name. but it was not owner.
owner 0x612cba5c not freed value_name

Breakpoint 6, fhandler_registry::fhandler_registry (this=0x612cb124)
at /tmp/winsup/winsup/cygwin/fhandler_registry.cc:417
417   prefix_len = sizeof ("registry") - 1;
8: this->value_name = 0x0
(gdb)
Continuing.

Breakpoint 6, fhandler_registry::fhandler_registry (this=0x612cb124)
at /tmp/winsup/winsup/cygwin/fhandler_registry.cc:417
417   prefix_len = sizeof ("registry") - 1;
8: this->value_name = 0x0
(gdb)
Continuing.

Breakpoint 6, fhandler_registry::fhandler_registry (this=0x612cb124)
at /tmp/winsup/winsup/cygwin/fhandler_registry.cc:417
417   prefix_len = sizeof ("registry") - 1;
8: this->value_name = 0x0
(gdb)
Continuing.

Breakpoint 9, fhandler_base::operator= (this=0x612cb124, x=...)
at /tmp/winsup/winsup/cygwin/fhandler.cc:42
42  {
4: &x = (fhandler_registry *) 0x612cba5c
(gdb)
Continuing.

0x612cb124_2->value_name = 0x612cba5c->value_name 0x612cb374 L"services" 
(freed but known as not freed)


Breakpoint 6, fhandler_registry::fhandler_registry (this=0x612cbd94)
at /tmp/winsup/winsup/cygwin/fhandler_registry.cc:417
417   prefix_len = sizeof ("registry") - 1;
8: this->value_name = 0x0
(gdb)
Continuing.

Breakpoint 6, fhandler_registry::fhandler_registry (this=0x612cbd94)
at /tmp/winsup/winsup/cygwin/fhandler_registry.cc:417
417   prefix_len = sizeof ("registry") - 1;
8: this->value_name = 0x0
(gdb)
Continuing.

Breakpoint 6, fhandler_registry::fhandler_registry (this=0x612cba5c)
at /tmp/winsup/winsup/cygwin/fhandler_re

Re: Slow performance Win7/64

[jojelino]

On 2011-07-29 오후 6:26, Corinna Vinschen wrote:

I've already recognize one positive side effect:
The CTRL-C Handler works now even faster.
With unpatched cygwin1.dll there was a realy long delay, after pressing CTRL-C.
Can you agree this too?


I agree sincerely.


The slowdown of the code was the result of a patch which was supposed
to fix a potential race condition.  Jojelino's patch looks nice, but
it might reintroduce a new race.  Handle with care.


The process are failing to fork with rare rate. (with make -j 10 command)
although i'm using cygwin with CFLAGS=-O4 -fomit-frame-pointer and 
disabling all {cygheap,}_CFLAGS. but in most occasions it works fine.



--
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: please fix heap_init

[jojelino]

On 2011-07-18 오후 5:45, Corinna Vinschen wrote:


I had a closer look and I found a bug in the code.  When no memory area
has been found which is bigger than the requested memory area, the code
was supposed to allocate the largest memory area found.  At this point
the code used start_address accidentally, rather than largest_found.
Is that what you were refering to?  If so, that should be fixed now in
CVS.


Corinna


Maybe I should have added your quote from the start.
Thank you for the fix.

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

please fix heap_init

[jojelino]

this is following of 'infinite recursion in git-svn'
#to reproduce this problem,
#1. please use latest cvs trunk
#2. set HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\heap_chunk_in_mb=0x400
Starting program: /usr/bin/perl.exe /usr/lib/git-core/git-svn clone 
-rHEAD http://google-perftools.googlecode.com/svn/trunk/

[New Thread 5352.0x9c4]
warning: section .gnu_debuglink not found in 
/cygdrive/d/cygwin/bin/cygwin1.dbg


Breakpoint 1, heap_init () at /tmp/winsup/winsup/cygwin/heap.cc:81
81start_address = roundup2 (start_address + 
mbi.RegionSize,

2: largest_found_size = 0x3568
1: start_address = 0x5569
(gdb) i b
Num Type   Disp Enb AddressWhat
1   breakpoint keep y   0x61078875 in heap_init()
   at 
/tmp/winsup/winsup/cygwin/heap.cc:81

breakpoint already hit 1 time
(gdb)

start_address continues to grow, and in heap.cc:94 it is used as base 
address.

which is not we wanted. and sbrk could fail if it used up MINHEAP_SIZE.

please fix this problem
Regards



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

please update winsup/cygwin/config/i386/profile.h

[jojelino]

i think you guys already fixed it on mingw. 
http://sourceforge.net/tracker/index.php?func=detail&aid=1211187&group_id=2435&atid=102435

but not for cygwin.
it results sigsegv in cygwin for profiling regparm(x) function.
please execute
cp -f winsup/mingw/profile/profile.h winsup/cygwin/config/i386/profile.h

regards.


--
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: [patch]another sigsegv in environ.cc

[jojelino]

changes introduced.

all file: add __attribute__ ((regparm (x))) explicitly in function 
definition.

environ.cc fix findenv_func that were not prefixed __stdcall
exception.h add body to prevent compilation error with -DDEBUG_EXCEPTION


fhandler_floppy.cc
hookapi.cc
syscalls.cc
in6.h
passwd.cc

merged with [PATCHes] Misc aliasing fixes for building DLL with gcc-4.5.0
Index: winsup/cygwin/environ.cc
===
RCS file: /cvs/src/src/winsup/cygwin/environ.cc,v
retrieving revision 1.183
diff -u -r1.183 environ.cc
--- winsup/cygwin/environ.cc18 May 2010 14:30:50 -  1.183
+++ winsup/cygwin/environ.cc9 Feb 2011 13:47:57 -
@@ -156,7 +156,7 @@
   to the beginning of the environment variable name.  *in_posix is any
   known posix value for the environment variable. Returns a pointer to
   the appropriate conversion structure.  */
-win_env * __stdcall
+win_env * __stdcall __attribute__ ((regparm (3)))
 getwinenv (const char *env, const char *in_posix, win_env *temp)
 {
   if (!conv_start_chars[(unsigned char)*env])
@@ -219,7 +219,7 @@
   free (src);
   MALLOC_CHECK;
 }
-
+typedef char* (__stdcall *pfnenv)(const char*,int*);
 /* Returns pointer to value associated with name, if any, else NULL.
   Sets offset to be the offset of the name/value combination in the
   environment array, for use by setenv(3) and unsetenv(3).
@@ -253,7 +253,7 @@
 
 /* Primitive getenv before the environment is built.  */
 
-static char __stdcall *
+static char* __stdcall
 getearly (const char * name, int *)
 {
   char *ret;
@@ -275,7 +275,7 @@
   return NULL;
 }
 
-static char * (*findenv_func)(const char *, int *) = (char * (*)(const char *, 
int *)) getearly;
+static pfnenv findenv_func = &getearly;
 
 /* Returns ptr to value associated with name, if any, else NULL.  */
 
@@ -830,7 +830,7 @@
   FreeEnvironmentStringsW (rawenv);
 
 out:
-  findenv_func = (char * (*)(const char*, int*)) my_findenv;
+  findenv_func = my_findenv;
   __cygwin_environ = envp;
   update_envptrs ();
   if (envp_passed_in)
@@ -856,7 +856,7 @@
   return strcmp (*p, *q);
 }
 
-char * __stdcall
+char * __stdcall __attribute__ ((regparm (3)))
 getwinenveq (const char *name, size_t namelen, int x)
 {
   WCHAR name0[namelen - 1];
@@ -956,7 +956,7 @@
filled with null terminated strings, terminated by double null characters.
Converts environment variables noted in conv_envvars into win32 form
prior to placing them in the string.  */
-char ** __stdcall
+char ** __stdcall __attribute__ ((regparm (3)))
 build_env (const char * const *envp, PWCHAR &envblock, int &envc,
   bool no_envblock)
 {
Index: winsup/cygwin/exception.h
===
RCS file: /cvs/src/src/winsup/cygwin/exception.h,v
retrieving revision 1.3
diff -u -r1.3 exception.h
--- winsup/cygwin/exception.h   1 Mar 2010 06:39:47 -   1.3
+++ winsup/cygwin/exception.h   9 Feb 2011 13:47:57 -
@@ -20,8 +20,8 @@
   static int handle (EXCEPTION_RECORD *, exception_list *, CONTEXT *, void *);
 public:
 #ifdef DEBUG_EXCEPTION
-  exception ();
-  ~exception ();
+  exception (){};
+  ~exception (){};
 #else
   exception () __attribute__ ((always_inline))
   {
Index: winsup/cygwin/fhandler_floppy.cc
===
RCS file: /cvs/src/src/winsup/cygwin/fhandler_floppy.cc,v
retrieving revision 1.57
diff -u -r1.57 fhandler_floppy.cc
--- winsup/cygwin/fhandler_floppy.cc12 Jan 2011 09:16:51 -  1.57
+++ winsup/cygwin/fhandler_floppy.cc9 Feb 2011 13:47:58 -
@@ -57,7 +57,8 @@
__seterrno ();
   else
{
- di = &((DISK_GEOMETRY_EX *) dbuf)->Geometry;
+ DISK_GEOMETRY_EX *dgx = (DISK_GEOMETRY_EX *) dbuf;
+ di = &dgx->Geometry;
  if (!DeviceIoControl (get_handle (),
IOCTL_DISK_GET_PARTITION_INFO_EX, NULL, 0,
pbuf, 256, &bytes_read, NULL))
Index: winsup/cygwin/hookapi.cc
===
RCS file: /cvs/src/src/winsup/cygwin/hookapi.cc,v
retrieving revision 1.19
diff -u -r1.19 hookapi.cc
--- winsup/cygwin/hookapi.cc11 Sep 2008 04:34:23 -  1.19
+++ winsup/cygwin/hookapi.cc9 Feb 2011 13:47:59 -
@@ -252,7 +252,7 @@
   fh.origfn = NULL;
   fh.hookfn = fn;
   char *buf = (char *) alloca (strlen (name) + sizeof ("_64"));
-  int i;
+  int i = -1;
   // Iterate through each import descriptor, and redirect if appropriate
   for (PIMAGE_IMPORT_DESCRIPTOR pd = pdfirst; pd->FirstThunk; pd++)
 {
Index: winsup/cygwin/syscalls.cc
===
RCS file: /cvs/src/src/winsup/cygwin/syscalls.cc,v
retrieving revision 1.573
diff -u -r1.573 syscalls.cc
--- winsup/cygwin/syscalls.cc   31 Jan 2011 13:58:59 -  1.573
+++ winsup/cygwin/syscalls.cc   9 Feb 2011 13:48:01 -
@@ -1569,7 +

Re: sigsegv in compiled cygwin

[jojelino]

Why the typedef?

cgf


int __stdcall (*wsastartup) (int, WSADATA *);

  /* Don't use autoload to load WSAStartup to eliminate recursion. */
  wsastartup = (int __stdcall (*)(int, WSADATA *))
   GetProcAddress ((HMODULE) (dll->handle), "WSAStartup");

adding __stdcall to both function pointer type would do the same.
there is not much reason about why i used typedef :( just saving few 
typing...

although you maybe not satisfied with that.


--
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: sigsegv in compiled cygwin

[jojelino]

i found small piece of code that need some comment.

from trunk

  int (*wsastartup) (int, WSADATA *);

  /* Don't use autoload to load WSAStartup to eliminate recursion. */
  wsastartup = (int (*)(int, WSADATA *))
   GetProcAddress ((HMODULE) (dll->handle), "WSAStartup");

would have meant
  typedef int __stdcall (*pfnwsastartup) (int, WSADATA *);
  pfnwsastartup wsastartup;
  wsastartup = (pfnwsastartup)
   GetProcAddress ((HMODULE) (dll->handle), "WSAStartup");

otherwise stack frame would be damaged.

On 2011-02-05 오전 12:01, Christopher Faylor wrote:

On Fri, Feb 04, 2011 at 09:40:46PM +0900, jojelino wrote:

i'm trying to build cygwin with gcc 4.6 trunk. and compile succeed.
but when i try to run cygwin-linked executables with new-compiled-one,
initialization routine failed with sigsegv  at win32_whatever+14

  0x61171a20<+0>: jmp0x61171a25
0x61171a25<+5>: mov0x61171a2c,%eax
0x61171a2a<+10>:call   *(%eax)
0x61171a2c<+12>:sbb%al,%al
=>  0x61171a2e<+14>:pop%ss

it seems redirection statement('Kludge alert') in autoload.cc didn't
work as expected.
what would i do??


Well, since you're trying to do something cutting edge and unsupported
it seems like you will have to debug the problem using gdb and, if you
really want this to work, make a change to autoload.cc to fix the
problem.  Look at a call frame for normal program and find where
the return address is stored.

Either that or wait for us to move to a newer version of gcc.

cgf





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

sigsegv in compiled cygwin

[jojelino]

i'm trying to build cygwin with gcc 4.6 trunk. and compile succeed.
but when i try to run cygwin-linked executables with new-compiled-one, 
initialization routine failed with sigsegv  at win32_whatever+14


 0x61171a20 <+0>: jmp0x61171a25 
   0x61171a25 <+5>: mov0x61171a2c,%eax
   0x61171a2a <+10>:call   *(%eax)
   0x61171a2c <+12>:sbb%al,%al
=> 0x61171a2e <+14>:pop%ss

it seems redirection statement('Kludge alert') in autoload.cc didn't 
work as expected.

what would i do??


--
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: it works well

[jojelino]

now it doesn't complains.
thank you sincerely.

"Christopher Faylor"  wrote in 
message news:20100101191658.ga32...@ednor.casa.cgf.cx...
> On Thu, Dec 31, 2009 at 11:25:53AM -0500, Christopher Faylor wrote:
>>On Thu, Dec 31, 2009 at 05:00:25PM +0900, jojelino wrote:
>>>hi
>>>here is testcase to reproduce the problem
>>>
>>>#include 
>>>#include 
>>>int main(int argc, char**argv)
>>>{
>>>printf("argv %s",argv[1]);
>>>open(argv[1],"r");
>>>assert(fp);
>>>return 0;
>>>}
>>>build
>>>make .txt in directory.
>>>and run in cmd.exe
>>>type,
>>>a ".txt"
>>>
>>>and it complains file can't be opened.
>>>and you can see argv[1]  is passed with preserved quote (") although it 
>>>is
>>>invoked in winshell
>>>it must be eliminted when it is transduced to cygwin environment.
>>
>>I don't see preserved quotes but I do see that ARGV has apparently been
>>changed to UTF-8 and is represented as: --.txt
>>
>>Try setting LANG to something appropriate in your MS-DOS session and see
>>if that makes things work better.
>
> I think I've fixed this problem in the upcoming cygwin snapshot at:
>
> http://cygwin.com/snapshots/
>
> if you want to give it a try.  It will be in *today's* snapshot, not the
> one from 12/29.
>
> cgf
> 




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

cygwin passes argv with preserved (") quote. and it is undesired result.

[jojelino]

hi
here is testcase to reproduce the problem

#include 
#include 
int main(int argc, char**argv)
{
printf("argv %s",argv[1]);
open(argv[1],"r");
assert(fp);
return 0;
}
build
make ¤±.txt in directory.
and run in cmd.exe
type,
a "¤±.txt"

and it complains file can't be opened.
and you can see argv[1]  is passed with preserved quote (") although it is 
invoked in winshell
it must be eliminted when it is transduced to cygwin environment.

but when parent process is cygwin, it gives no complaint
>strace a "¤±.txt"
in result, is it designed to do so?
(well i assume it bug.)
if not, how this can be avoided?? 




--
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: undefined reference to `___real__Znwj'

[jojelino]

thanks for replying. i needed it!
in fact, there is no need to change whole problematic cygwin source code to 
fix aliasing problem..
for me, just getting rid of '-Werror' from makefile.in resolves the problem.
it just complains for some lines of warning :)
"Dave "What part of PCYMTNQREAIYR isn't obvious? ;-)" Korn" 
 wrote in message 
news:4b2bdfab.2020...@googlemail.com...
> jojelino wrote:
>
>>> make -j 10 because of speed gain.
>> and it complains.. which i reported it.
>> so i got
>>> cd i686-pc-cygwin/winsup
>> and >make  again.
>> and it complains when it comes to cygserver.exe
>>
>> this could be answer for your question?
>
>  I was just curious how you got as far as building cygserver.exe without
> running into earlier problems compiling the cygwin1.dll; it doesn't build
> using 4.5.0 without a lot of patching.
>
>  Anyway, thanks for the bug report; you reminded me that I stumbled across
> this bug earlier in the summer but put it to one side because 4.5.0 was 
> still
> a long way from release.  Time to fix it, particularly now that the 
> libstdc++
> changes have gone in.
>
>  The problem is a bug in the linker, so you'll need to check out binutils
> from sourceware.org cvs and apply the attached
> weaksyms-vs-undefs-order-of-ref-fix-take-2.diff patch.  You'll also need 
> the
> other attached patch for the winsup/cygwin repository before it will all
> compile correctly with 4.5.0; there are a number of aliasing problems to 
> which
> 4.5.0 is more sensitive than earlier GCCs.
>
>  (I'll be feeding these patches back upstream in due course, once I've 
> given
> them all some further testing, but they build an apparently fully working
> 4.5.0-compiled cygwin1.dll so far, anyway.)
>
>cheers,
>  DaveK
>





> 




--
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: undefined reference to `___real__Znwj'

[jojelino]

oh my.. this is exact step i used.
compile gcc with latest git reprository
i used
>./configure --prefix=/usr/local/cc --enable-newlib-mb --enable-newlib-iconv 
> --enable-newlib-multithread
to build cygwin. (it would be good to clarify i got from cvs. so cygwin 
1.7.2)
>make -j 10 because of speed gain.
and it complains.. which i reported it.
so i got
>cd i686-pc-cygwin/winsup
and >make  again.
and it complains when it comes to cygserver.exe

this could be answer for your question?

"Dave Korn"  wrote in message 
news:4b2ab7c2.3000...@gmail.com...
> jojelino wrote:
>> tested with gcc version 4.5.0 20091217 (experimental) (GCC)
>
>  You're going to have to describe the exact steps to reproduce this 
> problem.
> As far as I can see the winsup directory doesn't come anywhere close to
> building with 4.5.0 at the moment, so I don't understand what exactly 
> you're
> doing.
>
>cheers,
>  DaveK
>
> 




--
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: undefined reference to `___real__Znwj'

[jojelino]

i'm using GNU nm (GNU Binutils) 2.20.51.20091023

"Dave Korn"  wrote in message 
news:4b2a8f0f.7060...@gmail.com...
> jojelino wrote:
>> tested with gcc version 4.5.0 20091217 (experimental) (GCC)
>
>> cygwin0.dll have __real__z* symbol...
>
>> /tmp/winsup/i686-pc-cygwin/winsup/cygwin/libcygwin.a(_cygwin_crt0_common.o):_cyg
>> win_crt0_common.cc:(.data+0x0): undefined reference to `___real__Znwj'
>> /tmp/winsup/i686-pc-cygwin/winsup/cygwin/libcygwin.a(_cygwin_crt0_common.o):_cyg
>> win_crt0_common.cc:(.data+0x4): undefined reference to `___real__Znaj'
>> /tmp/winsup/i686-pc-cygwin/winsup/cygwin/libcygwin.a(_cygwin_crt0_common.o):_cyg
>> win_crt0_common.cc:(.data+0x8): undefined reference to `___real__ZdlPv'
>> collect2: ld returned 1 exit status
>
>  Thanks for the report; I'll see if I can reproduce it.  Just to check, 
> you
> are using up-to-date binutils?
>
>cheers,
>  DaveK
> 




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

undefined reference to `___real__Znwj'

[jojelino]

tested with gcc version 4.5.0 20091217 (experimental) (GCC)
perl v5.10.1 (this is weird . it complains .)
cannot remove path when cwd is /tmp/fbRcNjc7xj for /tmp/fbRcNjc7xj:  at
/usr/lib
/perl5/5.10/File/Temp.pm line 902

cygwin0.dll have __real__z* symbol...
it seems it should have been eliminated after linking...
well it seems that gcc compiler can't handle properly c++ symbols...
how to workaround this problem?? any suggestions are welcomed.

$ nm -s cygwin0.dll |grep -E "_Z(n|d)"
61002430 T __ZdaPv
61002410 T __ZdaPvRKSt9nothrow_t
61002420 T __ZdlPv
61002400 T __ZdlPvRKSt9nothrow_t
610024a0 T __Znaj
61002460 T __ZnajRKSt9nothrow_t
61002480 T __Znwj
61002440 T __ZnwjRKSt9nothrow_t
 U ___real__ZdaPv
 U ___real__ZdlPv
 U ___real__Znaj
 U ___real__Znwj
61072120 T ___wrap__ZdaPv
61072160 T ___wrap__ZdaPvRKSt9nothrow_t
61072110 T ___wrap__ZdlPv
61072150 T ___wrap__ZdlPvRKSt9nothrow_t
61072100 T ___wrap__Znaj
61072140 T ___wrap__ZnajRKSt9nothrow_t
610720f0 T ___wrap__Znwj
61072130 T ___wrap__ZnwjRKSt9nothrow_t

>>>nm -s _cygwin_crt0_common.o
 A .weak.___real__zdapv.__cygwin_crt0_com...@8
 A .weak.___real__zdapvrkst9nothrow_t.__cygwin_crt0_com...@8
 A .weak.___real__zdlpv.__cygwin_crt0_com...@8
 A .weak.___real__zdlpvrkst9nothrow_t.__cygwin_crt0_com...@8
 A .weak.___real__znaj.__cygwin_crt0_com...@8
 A .weak.___real__znajrkst9nothrow_t.__cygwin_crt0_com...@8
 A .weak.___real__znwj.__cygwin_crt0_com...@8
 A .weak.___real__znwjrkst9nothrow_t.__cygwin_crt0_com...@8
 U _getmodulehand...@4
 U ___CTOR_LIST__
 U ___DTOR_LIST__
 D ___cygwin_cxx_malloc
 U ___dynamically_loaded
 w ___real__ZdaPv
 w ___real__ZdaPvRKSt9nothrow_t
 w ___real__ZdlPv
 w ___real__ZdlPvRKSt9nothrow_t
 w ___real__Znaj
 w ___real__ZnajRKSt9nothrow_t
 w ___real__Znwj
 w ___real__ZnwjRKSt9nothrow_t

$ nm -s libcygwin.a |grep -E "_Z(n|d)"
__impwrap__ZdaPv in d87.o
__impwrap__ZdaPvRKSt9nothrow_t in d88.o
__impwrap__ZdlPv in d89.o
__impwrap__ZdlPvRKSt9nothrow_t in d90.o
__impwrap__Znaj in d91.o
__impwrap__ZnajRKSt9nothrow_t in d92.o
__impwrap__Znwj in d93.o
__impwrap__ZnwjRKSt9nothrow_t in d94.o
___wrap__ZdaPv in t-d87.o
___wrap__ZdaPvRKSt9nothrow_t in t-d88.o
___wrap__ZdlPv in t-d89.o
___wrap__ZdlPvRKSt9nothrow_t in t-d90.o
___wrap__Znaj in t-d91.o
___wrap__ZnajRKSt9nothrow_t in t-d92.o
___wrap__Znwj in t-d93.o
___wrap__ZnwjRKSt9nothrow_t in t-d94.o
.weak.___real__zdapvrkst9nothrow_t.__cygwin_crt0_com...@8 in _cygwin_crt0_
.o
.weak.___real__zdlpvrkst9nothrow_t.__cygwin_crt0_com...@8 in _cygwin_crt0_
.o
.weak.___real__znajrkst9nothrow_t.__cygwin_crt0_com...@8 in _cygwin_crt0_c
o
.weak.___real__znwjrkst9nothrow_t.__cygwin_crt0_com...@8 in _cygwin_crt0_c
o
.weak.___real__zdapv.__cygwin_crt0_com...@8 in _cygwin_crt0_common.o
.weak.___real__zdlpv.__cygwin_crt0_com...@8 in _cygwin_crt0_common.o
.weak.___real__znaj.__cygwin_crt0_com...@8 in _cygwin_crt0_common.o
.weak.___real__znwj.__cygwin_crt0_com...@8 in _cygwin_crt0_common.o
 I __impwrap__ZdaPv
 I __impwrap__ZdaPvRKSt9nothrow_t
 I __impwrap__ZdlPv
 I __impwrap__ZdlPvRKSt9nothrow_t
 I __impwrap__Znaj
 I __impwrap__ZnajRKSt9nothrow_t
 I __impwrap__Znwj
 I __impwrap__ZnwjRKSt9nothrow_t
 T ___wrap__ZdaPv
 U __impwrap__ZdaPv
 T ___wrap__ZdaPvRKSt9nothrow_t
 U __impwrap__ZdaPvRKSt9nothrow_t
 T ___wrap__ZdlPv
 U __impwrap__ZdlPv
 T ___wrap__ZdlPvRKSt9nothrow_t
 U __impwrap__ZdlPvRKSt9nothrow_t
 T ___wrap__Znaj
 U __impwrap__Znaj
 T ___wrap__ZnajRKSt9nothrow_t
 U __impwrap__ZnajRKSt9nothrow_t
 T ___wrap__Znwj
 U __impwrap__Znwj
 T ___wrap__ZnwjRKSt9nothrow_t
 U __impwrap__ZnwjRKSt9nothrow_t
 A .weak.___real__zdapv.__cygwin_crt0_com...@8
 A .weak.___real__zdapvrkst9nothrow_t.__cygwin_crt0_com...@8
 A .weak.___real__zdlpv.__cygwin_crt0_com...@8
 A .weak.___real__zdlpvrkst9nothrow_t.__cygwin_crt0_com...@8
 A .weak.___real__znaj.__cygwin_crt0_com...@8
 A .weak.___real__znajrkst9nothrow_t.__cygwin_crt0_com...@8
 A .weak.___real__znwj.__cygwin_crt0_com...@8
 A .weak.___real__znwjrkst9nothrow_t.__cygwin_crt0_com...@8
 w ___real__ZdaPv
 w ___real__ZdaPvRKSt9nothrow_t
 w ___real__ZdlPv
 w ___real__ZdlPvRKSt9nothrow_t
 w ___real__Znaj
 w ___real__ZnajRKSt9nothrow_t
 w ___real__Znwj
 w ___real__ZnwjRKSt9nothrow_t

>$ nm -s libcygwin.a |grep -E "_Z(n|d)"
__impwrap__ZdaPv in d87.o
__impwrap__ZdaPvRKSt9noth