This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: ls output still truncated
Larry Hall (Cygwin) wrote:
> Frodak Baksik wrote:
>> 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?
>
>
> No, you're seeing all the data sent.
>
> Chuck, what's the error code returned from each case?
>
>
Error code in both cases is 0.
--
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/