Message-Id: <199903061623.LAA10573@delorie.com> Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm Sender: cygwin-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com From: "Paul Coward" Organization: DigiSoft Pty Ltd To: cygwin AT sourceware DOT cygnus DOT com Date: Sun, 7 Mar 1999 02:24:36 +1000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Stack problem in Beta 20.1 ??? Reply-to: paul AT asgard DOT net DOT au X-mailer: Pegasus Mail for Win32 (v3.01b) 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 AT sourceware DOT cygnus DOT com