This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: ls output still truncated
On 2/20/07, Chuck wrote:
Your wish is my command. Attached are two strace output files. The names
should be self-explanatory. Please let me know if you see anything. In
the mean time I'm going to refresh myself on the use of gcc and gdb and
see if I can trace the execution of ls. Like I said in another post
though, it's been a *very* long time since I've done any C programming
and I don't think I've ever used the gnu debugger.
<SNIP TRACE DATA>
I'm using gmail and the traces are embedded in the email, so forgive
me if I'm way off base.
If these are the full traces, then when it works ls runs fine. When
it doesn't work ls was killed somehow. In the first trace file the
last line is:
62 11096 [main] ls 1036 normalize_win32_path: c:\Program Files\QuickTime\QTSystem\ = normalize_win32_path (c:\Program Files\QuickTime\QTSystem\)
Notice that ls never performed a closedir or wrote any data out.
The last trace file shows:
167 41916 [main] ls 3048 fhandler_disk_file::closedir: 0 = closedir (0x6A1A60)
178 42094 [main] ls 3048 closedir: 0 = closedir (0xA0000)
113 42207 [main] ls 3048 fhandler_base::fstat: here
59 42266 [main] ls 3048 fstat64: 0 = fstat (1, 0x22BA20)
372 42638 [main] ls 3048 sig_send: sendsig 0x6FC, pid 3048, signal -34, its_me 1
65 42703 [main] ls 3048 sig_send: wakeup 0x6C8
68 42771 [main] ls 3048 sig_send: Waiting for pack.wakeup 0x6C8
66 42837 [sig] ls 3048 wait_sig: signalling pack.wakeup 0x6C8
72 42909 [main] ls 3048 sig_send: returning 0x0 from sending signal -34
105 43014 [main] ls 3048 fhandler_base::write: binary write
Which got to the point where ls closed the dir handle and actually
wrote some data.
I don't know what would kill a process like that? Or am I just not
seeing all of the data?
--
Frodak
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/