* Stack problem in Beta 20.1 ???
@ 1999-03-06 8:23 Paul Coward
0 siblings, 0 replies; 2+ messages in thread
From: Paul Coward @ 1999-03-06 8:23 UTC (permalink / raw)
To: cygwin
Hi,
The following code fragment fails to compile correctly under 20.1 unless
the setjmp/longjmp pair are included to fix an apparant stack problem.
This code is run inside a loop and prints the correct values the first time
through but totally stuffs up on subsequent passes (unless the
setjmp/longjmp are present).
As near as I can tell the code seems to get the stack alignment wrong
after the first pass. The fact the the setjmp/longjmp pair seem to have
fixed the problem seems to support this assumption.
This is the first time that I have compiled a program with cygwin that
passes so many args on the stack (9 in the case of
PRN_SetPrintText()). Could this be the cause of the problem?
The values passed don't matter. Even the fprintf call stuffs up with too
many parameters passed.
if (setjmp(jmpBuf) == 0) {
#ifdef DEBUG_PRN
fprintf(stderr, " Push constants\n");
fprintf(stderr, " (left) %ld\n (top) %ld\n (charType) %d\n
(charWidth)
%d\n (charHeight) %d\n (charRot) %d\n (stringRot) %d\n
(charSpace) %d)\n",
((long) (((double) text->tfLeft) / TWIPS_PER_THERM)),
((long) (((double) text->tfTop) / TWIPS_PER_THERM)),
1, 1, 1, 0, 0, 3);
fprintf(stderr, " Push normal\n");
fprintf(stderr, " (left) %ld\n (top) %ld\n (charType) %ld\n
(charWidth)
%ld\n (charHeight) %ld\n (charRot) %ld\n (stringRot) %ld\n
(charSpace)
%ld)\n",
((long) (((double) text->tfLeft) / TWIPS_PER_THERM)),
((long) (((double) text->tfTop) / TWIPS_PER_THERM)),
charType, charWidth, charHeight, charRot, stringRot,
charSpace);
fprintf(stderr, "PRN_SetPrintText(\"%s\"\n\t(left) %d\n\t(top)
%d\n\t(charType)
%d\n\t(charWidth) %d\n\t(charHeight) %d\n\t(charRot) %d\n\t(stringRot)
%d\n\t(charSpace) %d)\n",
text->tfText,
((long) (((double) text->tfLeft) / TWIPS_PER_THERM)),
((long) (((double) text->tfTop) / TWIPS_PER_THERM)),
charType, charWidth, charHeight, charRot, stringRot,
charSpace);
#endif
result = PRN_SetPrintText(text->tfText,
((long) (((double) text->tfLeft) / TWIPS_PER_THERM)),
((long) (((double) text->tfTop) / TWIPS_PER_THERM)),
charType,
charWidth,
charHeight,
charRot,
stringRot,
charSpace);
if (result != PRN_SUCCESS) {
LogError("Failed SetPrintText() call for \"%s\" (return code
0x%08x)",
text->tfText, result);
Shutdown(1);
}
longjmp(jmpBuf, 1);
}
Of course, it could be my fault. I've spent 2 days trying to find a
problem in my code. It wasn't until I started to suspect the compiler
and included setjmp that the problem disappeared.
If this is found to be a bug in cygwin could someone please mail me
direct as I don't subscribe to this list.
Thanks
Paul Coward.
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 2+ messages in thread
* Stack problem in Beta 20.1 ???
@ 1999-03-31 19:45 Paul Coward
0 siblings, 0 replies; 2+ messages in thread
From: Paul Coward @ 1999-03-31 19:45 UTC (permalink / raw)
To: cygwin
Hi,
The following code fragment fails to compile correctly under 20.1 unless
the setjmp/longjmp pair are included to fix an apparant stack problem.
This code is run inside a loop and prints the correct values the first time
through but totally stuffs up on subsequent passes (unless the
setjmp/longjmp are present).
As near as I can tell the code seems to get the stack alignment wrong
after the first pass. The fact the the setjmp/longjmp pair seem to have
fixed the problem seems to support this assumption.
This is the first time that I have compiled a program with cygwin that
passes so many args on the stack (9 in the case of
PRN_SetPrintText()). Could this be the cause of the problem?
The values passed don't matter. Even the fprintf call stuffs up with too
many parameters passed.
if (setjmp(jmpBuf) == 0) {
#ifdef DEBUG_PRN
fprintf(stderr, " Push constants\n");
fprintf(stderr, " (left) %ld\n (top) %ld\n (charType) %d\n
(charWidth)
%d\n (charHeight) %d\n (charRot) %d\n (stringRot) %d\n
(charSpace) %d)\n",
((long) (((double) text->tfLeft) / TWIPS_PER_THERM)),
((long) (((double) text->tfTop) / TWIPS_PER_THERM)),
1, 1, 1, 0, 0, 3);
fprintf(stderr, " Push normal\n");
fprintf(stderr, " (left) %ld\n (top) %ld\n (charType) %ld\n
(charWidth)
%ld\n (charHeight) %ld\n (charRot) %ld\n (stringRot) %ld\n
(charSpace)
%ld)\n",
((long) (((double) text->tfLeft) / TWIPS_PER_THERM)),
((long) (((double) text->tfTop) / TWIPS_PER_THERM)),
charType, charWidth, charHeight, charRot, stringRot,
charSpace);
fprintf(stderr, "PRN_SetPrintText(\"%s\"\n\t(left) %d\n\t(top)
%d\n\t(charType)
%d\n\t(charWidth) %d\n\t(charHeight) %d\n\t(charRot) %d\n\t(stringRot)
%d\n\t(charSpace) %d)\n",
text->tfText,
((long) (((double) text->tfLeft) / TWIPS_PER_THERM)),
((long) (((double) text->tfTop) / TWIPS_PER_THERM)),
charType, charWidth, charHeight, charRot, stringRot,
charSpace);
#endif
result = PRN_SetPrintText(text->tfText,
((long) (((double) text->tfLeft) / TWIPS_PER_THERM)),
((long) (((double) text->tfTop) / TWIPS_PER_THERM)),
charType,
charWidth,
charHeight,
charRot,
stringRot,
charSpace);
if (result != PRN_SUCCESS) {
LogError("Failed SetPrintText() call for \"%s\" (return code
0x%08x)",
text->tfText, result);
Shutdown(1);
}
longjmp(jmpBuf, 1);
}
Of course, it could be my fault. I've spent 2 days trying to find a
problem in my code. It wasn't until I started to suspect the compiler
and included setjmp that the problem disappeared.
If this is found to be a bug in cygwin could someone please mail me
direct as I don't subscribe to this list.
Thanks
Paul Coward.
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~1999-03-31 19:45 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-03-06 8:23 Stack problem in Beta 20.1 ??? Paul Coward
1999-03-31 19:45 Paul Coward
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).