X-Spam-Check-By: sourceware.org
To: cygwin AT cygwin DOT com
From: =?ISO-8859-1?Q?Ren=E9_Berber?= <r DOT berber AT computer DOT org>
Subject:  Re: C exe redirection blank file
Date:  Mon, 08 May 2006 14:44:44 -0500
Lines: 154
Message-ID: <e3o73e$hpu$1@sea.gmane.org>
References:  <4e225417b8AndyBurgess AT argonet DOT co DOT uk> <e3g084$921$1 AT sea DOT gmane DOT org> <4e2269bfcfAndy AT jet-net DOT co DOT uk> <e3gi0p$23s$1 AT sea DOT gmane DOT org> <4e22e3825fAndy AT jet-net DOT co DOT uk> <e3j244$4hm$1 AT sea DOT gmane DOT org> <4e23bac6d1Andy AT jet-net DOT co DOT uk>
Mime-Version:  1.0
Content-Type:  text/plain; charset=ISO-8859-1
Content-Transfer-Encoding:  quoted-printable
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
In-Reply-To: <4e23bac6d1Andy@jet-net.co.uk>
OpenPGP: url=hkp://random.sks.keyserver.penguin.de
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
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

Andy AT Jet-Net wrote:
[snip]
> Incidentally I did have trouble with the serial port baud rate, and incre=
ased
> programmatically for this program up to 38400 (from 9600). Would this have
> any bearing? It's the same on both PCs (and same hardware attached to eac=
h on
> the same port number).

Don't think so.

> However, just recompiled another program that uses the same serial-port
> handler and string-handler (include files), copied over to 'live' and it =
can
> redirect OK. Limits it down to main() or the one remaining include file (=
big
> one) of this program! I may experiment with it while I eagerly await your
> reply.
>=20
>> There are many possibilities but none will stand if the program works
>> one way on a computer and another way on a different computer.  So the m=
ost
>> probable cause is some difference between computers.
> Right, been looking into that. I have the following set up
>=20
> PROBLEM PC:
>=20
>         I'm using .bash_profile to set things, rather than a user profile=
 (not created).
>         I'm using the variable $CC to hold the working directory (would t=
his conflict with a c compiler variable?).

CC is only used by make and configure scripts.

>         On this PC I set up the variable in the following way (at the end=
 of .bash_profile):
>=20
>         CC=3Dc:/dir
>         export $CC
>         cd $CC
>=20
>         in ENV:
>         HOMEPATH=3D\Documents and Settings\Andy
>         PROCESSOR_IDENTIFIER=3Dx86 Family 15 Model 1 Stepping 2, GenuineI=
ntel
>         OLDPWD=3D/home/Andy
>         !C:=3DC:\cygwin\bin
>         HOME=3D/home/Andy
>         HOMEDRIVE=3DC:
>         CC=3Dc:/dir
>=20
> WORKING PC:
>=20
>         I use my username's .profile.
>         I set up the variable $CDIR to hold the working directory.
>         On this PC I set up the variable in the following way:
>=20
>         created Windows "Environment Variable" %cdir% as "e:/c/workshop/d=
ir"
>         in my user ".profile" I do
>         cd $CDIR
>=20
>         in ENV:
>         HOMEPATH=3D\
>         PROCESSOR_IDENTIFIER=3Dx86 Family 15 Model 3 Stepping 4, GenuineI=
ntel
>         OLDPWD=3D/cygdrive/b (connecting to remote drive on Bad PC)
>         !C:=3DC:\
>         HOME=3D//computer/data
>         HOMEDRIVE=3DT: (a share I mapped previously in Windows).
>         CC=3D/usr/bin/gcc.exe (although I don't use $CC otherwise)
>=20
> The USER and MAKEMODE details are the same. I have other C compilers
> installed on the Good PC. The problem PC also has TEXDOCVIEW entries? Wou=
ld
> any of this affect my processing? Would any other env entries help with
> clarification?

No, on all questions.

[snip]
> An uninitialised pointer, you say? I'm only using character pointers. I
> suppose an "uninitialised" one would just be used (in say strcpy) rather =
than
> having been set beforehand. How can you detect it in GDB?

Any pointer can be misused, the best way to detect problems is using someth=
ing
like Electric Fence (efence) or similar, but I don't think they detect "ran=
dom"
pointers (the effect of uninitialized pointers).

Best way to find out if that is the problem: initialize all pointers to nul=
l.

>> if the program is not too complex I would use gdb to see the execution at
>> least once, if it is complex then better isolate the problem first.
> Ok, it's not *too* complicated. How would you advise using GDB to test th=
is
> issue? I've only just learnt that tool. What should I be checking for -
> adding a watch on "stdout" or something?

No, my idea is to run the program step by step following the source code.  =
On
the other hand, yes, you could use a watch on the real variable (stdout is a
macro so it's not that easy to track, but it may be necessary).

On the target machine you probably don't have all the necessary tools, so t=
his
could be a lot of work.  You need the equivalent of an IDE (to look at the =
code
and values of variables at the same time).

It is easier just to initialize pointers to null.  That is, since I suspect=
 that
the file descriptor table is being overwritten.

>>> * Does windows have a lock on a file or something?
>> Yes.  You probably have seen it, when Windows doesn't allow you to delete
>> a file because it is "in use"
> Oh yes, I've seen it - especially on Windows 3.1! Bearing in mind I've
> rebooted a few time, I don't think that'd happen again - would it?

What would happen again?  The point here was that Windows does have some ki=
nd of
locks... if you don't use them then it has no relevance to the problem.

[snip]
> I also run in on the development machine in a different folder structure -
> e:\C\workshop\dir. Cygwin is installed on the E drive on the development
> machine, and on C on the 'live' machine.
>=20
> This reminds me of configuring serial printers.... settings had to match =
on
> both the terminal and the printer!

Right now it looks more like a program error, it is strange that the problem
appears to be in only the target computer, that lead me to believe there was
something different but maybe not.
--=20
Ren=E9 Berber


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