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: C exe redirection blank file


Andy@Jet-Net wrote:
[snip]
> Incidentally I did have trouble with the serial port baud rate, and increased
> 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 each 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.
> 
>> 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 most
>> probable cause is some difference between computers.
> Right, been looking into that. I have the following set up
> 
> PROBLEM PC:
> 
>         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 this 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):
> 
>         CC=c:/dir
>         export $CC
>         cd $CC
> 
>         in ENV:
>         HOMEPATH=\Documents and Settings\Andy
>         PROCESSOR_IDENTIFIER=x86 Family 15 Model 1 Stepping 2, GenuineIntel
>         OLDPWD=/home/Andy
>         !C:=C:\cygwin\bin
>         HOME=/home/Andy
>         HOMEDRIVE=C:
>         CC=c:/dir
> 
> WORKING PC:
> 
>         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:
> 
>         created Windows "Environment Variable" %cdir% as "e:/c/workshop/dir"
>         in my user ".profile" I do
>         cd $CDIR
> 
>         in ENV:
>         HOMEPATH=\
>         PROCESSOR_IDENTIFIER=x86 Family 15 Model 3 Stepping 4, GenuineIntel
>         OLDPWD=/cygdrive/b (connecting to remote drive on Bad PC)
>         !C:=C:\
>         HOME=//computer/data
>         HOMEDRIVE=T: (a share I mapped previously in Windows).
>         CC=/usr/bin/gcc.exe (although I don't use $CC otherwise)
> 
> 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? Would
> 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 something
like Electric Fence (efence) or similar, but I don't think they detect "random"
pointers (the effect of uninitialized pointers).

Best way to find out if that is the problem: initialize all pointers to null.

>> 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 this
> 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 this
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 kind 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.
> 
> 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.
-- 
René 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/


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