X-Spam-Check-By: sourceware.org
Message-ID: <9ae083a20702201313k52dad10frf49a192d126bc56@mail.gmail.com>
Date: Tue, 20 Feb 2007 16:13:32 -0500
From: "Frodak Baksik" <frodak17 AT gmail DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: ls output still truncated
In-Reply-To: <erfneq$6v6$1@sea.gmane.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <erfe79$avu$1 AT sea DOT gmane DOT org> <45DB4B01 DOT 90002 AT cygwin DOT com> 	 <erfk4a$dcf$1 AT sea DOT gmane DOT org> <45DB56F4 DOT 60800 AT cygwin DOT com> 	 <erfneq$6v6$1 AT sea DOT gmane DOT org>
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

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/