This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]