Mail Archives: cygwin/2006/05/08/15:45:22
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/
- Raw text -