Re: sqlcmd stackdump

Hi again, I found the position in the source where the dump is created, but don't know why this happens. sqlstmt.ec static void sql_select(Sqlda *idesc, int stmt_code) ... count = 0; while (sqlca.sqlcode == 0) { printf("sql_select 5\\n"); EXEC SQL FETCH c_statement USING DESCRIPTOR idesc; printf("sql_select 5.1\\n"); if (sqlca.sqlcode != 0) break; printf("sql_select 5.2\\n"); if (qlimit > 0 && count++ >= qlimit) { printf("sql_select 5.3\\n"); fflush(ctxt_output()); break; } printf("sql_select 6\\n"); if (print_record(idesc) != 0) break; printf("sql_select 7\\n"); } Output: D:\\Software.tmp\\Informix\\sqlcmd\\sqlcmd-86.00>sqlcmd -u informix -p m$x1bst -d test SQL[12]: select * from hallo; sql_select 0/nsql_select 1/nsql_select 2/nsql_select 3/nsql_select 4/nsql_select 5 sql_select 5.1 sql_select 5.2 sql_select 6 hallo sql_select 7 sql_select 5 sql_select 5.1 1 [main] sqlcmd 2132 exception::handle: Exception: STATUS_ACCESS_VIOLATION 593 [main] sqlcmd 2132 open_stackdumpfile: Dumping stack trace to sqlcmd.exe.stackdump 6042 [main] sqlcmd 2132 exception::handle: Exception: STATUS_ACCESS_VIOLATION 5295 [main] sqlcmd 2132 exception::handle: Error while dumping state (probably corrupted stack) It looks like the EXEC SQL crashes the memory and then the access to the sqlca.sqlcode is damaged. But why? Is there any special gcc parameter that will prevent this? TIA Dirk Dirk Niemeier schrieb: > > Hi, > I compiled sqlcmd from JL for Windows XP 32bit. > The following statement dumps while an exception occurs. > > D:\\Informix_DBImport>sqlcmd -u informix -p mypwd -d test 'select * > from hallo' > hallo > > 1 [main] sqlcmd 3868 exception::handle: Exception: > STATUS_ACCESS_VIOLATION > > 474 [main] sqlcmd 3868 open_stackdumpfile: Dumping stack trace to > sqlcmd.exe.stackdump > > 2775 [main] sqlcmd 3868 exception::handle: Exception: > STATUS_ACCESS_VIOLATION > - 747 [main] sqlcmd 3868 exception::handle: Error while dumping state > (probably corrupted stack) > > a second call generates the following: > > D:\\Informix_DBImport>sqlcmd -u informix -p mypwd -d test -e 'select * > from hallo' > hallo > > 6 [sig] sqlcmd 5484 open_stackdumpfile: Dumping stack trace to > sqlcmd.exe.stackdump > > D:\\Informix_DBImport>sqlcmd -u informix -p mypwd -d test 'select * > from hallo' > hallo > > 16 [sig] sqlcmd 5532 open_stackdumpfile: Dumping stack trace to > sqlcmd.exe.stackdump > > The table hallo has only one column called hallo. > > Here is the core file: > Stack trace: > Frame Function Args > 0022C7F8 7C802542 (0000065C, 0000EA60, 000000A4, 0022C8EC) > 0022C908 610C2643 (00000000, 7C802600, 7C802542, 00000000) > 0022C9E8 610BF2F7 (00000000, 00000000, 00000000, 00000000) > 0022CA38 610BF70B (0000159C, 0022CA60, 00000000, 78134C58) > 0022CAF8 610BF831 (0000159C, 00000006, 0022CB28, 610BF8D5) > 0022CB08 610BF86C (00000006, 0022CE80, 00000000, 00000000) > 0022CB28 610BF8D5 (00000000, 0022CB48, 62D03AD9, 00000009) > 0022CBB8 610ED58D (00D22138, 0022CBFC, 58585858, 58585858) > 0022CC68 004095B6 (00D22138, 00000020, 00000007, 00402689) > 0022CD18 004030E5 (00000008, 00D08738, 00D085E8, 00000001) > 0022CD98 61006E73 (00000000, 0022CDD4, 61006720, 7FFDE000) > End of stack trace > > D:\\Informix_DBImport>sqlcmd -h > sqlcmd: SQLCMD Version 86.00 (2008-07-15) > IBM Informix CSDK Version 3.50, IBM Informix-ESQL Version 3.50.TC6 > Licenced under GNU General Public Licence Version 2 ...... > > I think there is a problem im my compilition. Perhaps anybody has an > other compiled Windows version? > > TIA > Dirk > > > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list >

On Jul 9, 4:03 am, Dirk Niemeier <dirk.nieme...@stueken.de> wrote: > Hi again, > I found the position in the source where the dump is created, but don't > know why this happens. > sqlstmt.ec > > static void     sql_select(Sqlda *idesc, int stmt_code) > ... >         count = 0; >         while (sqlca.sqlcode == 0) >         { >     printf("sql_select 5\\n"); >             EXEC SQL FETCH c_statement USING DESCRIPTOR idesc; >     printf("sql_select 5.1\\n"); >             if (sqlca.sqlcode != 0) >                 break; >     printf("sql_select 5.2\\n"); >             if (qlimit > 0 && count++ >= qlimit) >             { >     printf("sql_select 5.3\\n"); >                 fflush(ctxt_output()); >                 break; >             } >     printf("sql_select 6\\n"); >             if (print_record(idesc) != 0) >                 break; >     printf("sql_select 7\\n"); >         } > > Output: > > D:\\Software.tmp\\Informix\\sqlcmd\\sqlcmd-86.00>sqlcmd -u informix -p > m$x1bst -d test > SQL[12]: select * from hallo; > sql_select 0/nsql_select 1/nsql_select 2/nsql_select 3/nsql_select > 4/nsql_select 5 > sql_select 5.1 > sql_select 5.2 > sql_select 6 > hallo > sql_select 7 > sql_select 5 > sql_select 5.1 >       1 [main] sqlcmd 2132 exception::handle: Exception: > STATUS_ACCESS_VIOLATION >     593 [main] sqlcmd 2132 open_stackdumpfile: Dumping stack trace to > sqlcmd.exe.stackdump >    6042 [main] sqlcmd 2132 exception::handle: Exception: > STATUS_ACCESS_VIOLATION >    5295 [main] sqlcmd 2132 exception::handle: Error while dumping state > (probably corrupted stack) > > It looks like the EXEC SQL crashes the memory and then the access to the > sqlca.sqlcode is damaged. But why? > Is there any special gcc parameter that will prevent this? > Given that the problem occurs where you say, I suspect that there must be a problem in the setup of the descriptor that the FETCH is using, most likely some form of memory abuse. I've not had SQLCMD running on Windows (too lazy) for quite a long time. There's one other possibility I can think of - also memory abuse - is that the 'sqlca' is actually being mapped to a function that returns a pointer to the sqlca structure (normal in threaded ESQL/C - I don't know whether Windows ESQL/C uses threaded code automatically), and that pointer has been corrupted. I'll try to look sometime - maybe even sometime soon. But since it involves sorting out the Windows compilation environment on my laptop (I do have Cygwin up and running), it may take some time.

Jonathan Leffler wrote: > On Jul 9, 4:03 am, Dirk Niemeier <dirk.nieme...@stueken.de> wrote: >> Hi again, >> I found the position in the source where the dump is created, but don't >> know why this happens. >> sqlstmt.ec >> >> static void sql_select(Sqlda *idesc, int stmt_code) >> ... >> count = 0; >> while (sqlca.sqlcode == 0) >> { >> printf("sql_select 5\\n"); >> EXEC SQL FETCH c_statement USING DESCRIPTOR idesc; >> printf("sql_select 5.1\\n"); >> if (sqlca.sqlcode != 0) >> break; >> printf("sql_select 5.2\\n"); >> if (qlimit > 0 && count++ >= qlimit) >> { >> printf("sql_select 5.3\\n"); >> fflush(ctxt_output()); >> break; >> } >> printf("sql_select 6\\n"); >> if (print_record(idesc) != 0) >> break; >> printf("sql_select 7\\n"); >> } >> >> Output: >> >> D:\\Software.tmp\\Informix\\sqlcmd\\sqlcmd-86.00>sqlcmd -u informix -p >> m$x1bst -d test >> SQL[12]: select * from hallo; >> sql_select 0/nsql_select 1/nsql_select 2/nsql_select 3/nsql_select >> 4/nsql_select 5 >> sql_select 5.1 >> sql_select 5.2 >> sql_select 6 >> hallo >> sql_select 7 >> sql_select 5 >> sql_select 5.1 >> 1 [main] sqlcmd 2132 exception::handle: Exception: >> STATUS_ACCESS_VIOLATION >> 593 [main] sqlcmd 2132 open_stackdumpfile: Dumping stack trace to >> sqlcmd.exe.stackdump >> 6042 [main] sqlcmd 2132 exception::handle: Exception: >> STATUS_ACCESS_VIOLATION >> 5295 [main] sqlcmd 2132 exception::handle: Error while dumping state >> (probably corrupted stack) >> >> It looks like the EXEC SQL crashes the memory and then the access to the >> sqlca.sqlcode is damaged. But why? >> Is there any special gcc parameter that will prevent this? >> > > > Given that the problem occurs where you say, I suspect that there must > be a problem in the setup of the descriptor that the FETCH is using, > most likely some form of memory abuse. > > I've not had SQLCMD running on Windows (too lazy) for quite a long > time. > > There's one other possibility I can think of - also memory abuse - is > that the 'sqlca' is actually being mapped to a function that returns a > pointer to the sqlca structure (normal in threaded ESQL/C - I don't > know whether Windows ESQL/C uses threaded code automatically), and > that pointer has been corrupted. > > I'll try to look sometime - maybe even sometime soon. But since it > involves sorting out the Windows compilation environment on my laptop > (I do have Cygwin up and running), it may take some time. > If that helps, SQSL segv's in similar circumstances at about the 60th or so FETCH if the Informix data source is built using the Cygwin compiler in MinGW mode (building in native mode is a definite no-no, as the two memory management models are inherently incompatible), however, no such thing happens if the data source is built with MVS, even if the whole application is compiled and linked with Cygwin (in whatever mode). -- Ciao, Marco ______________________________________________________________________________ Marco Greco /UK /IBM Standard disclaimers apply! Structured Query Scripting Language http://www.4glworks.com/sqsl.htm 4glworks http://www.4glworks.com Informix on Linux http://www.4glworks.com/ifmxlinux.htm