http://www.perlmonks.org?node_id=1083378


in reply to Re^7: Strawberry Perl 64bit on Win7 crashes on DBI-function
in thread Strawberry Perl 64bit on Win7 crashes on DBI-function

You used the new DBD::ODBC because the original one does not do all those printfs. It is interesting you got to DSN 301 this time and the debug from before suggested you had 310 DSNs. Is there perhaps something different about the DSN DT70PDF or the following one DT33PDF? Can you look at them with the ODBC Administrator and see if there descriptions look different/long?

  • Comment on Re^8: Strawberry Perl 64bit on Win7 crashes on DBI-function

Replies are listed 'Best First'.
Re^9: Strawberry Perl 64bit on Win7 crashes on DBI-function
by theman824 (Novice) on Apr 24, 2014 at 06:40 UTC
    Back at work.

    What i found out:

    There's really nothing wrong with the ODBC-DSNs or the descriptions (apart from there being so many on our machines...). When i raise the buffer size of the cmd-window ("dos-box"), the whole list of the 310 DSNs actually appears. But (probably upon returning from some function) the interpreter still crashes.

    To make clear: After the complete list is retrieved it crashes. Only when I try to pipe the output to a file (to post here) it does not generate the complete list (eben if i add a "$| = 1").

    The longest description is 54 characters wide: /Excel Files/ (11), /Microsoft Excel Driver (*.xls, *.xlsx, *.xlsm, *.xlsb)/ (54) and should be a standard DSN on windows with office installed.

    I am out of ideas for now.

      If you get the full list and it segfaults (or whatever) afterwards it does sound like memory/stack corruption but assuming you are using the new version I sent you yesterday I cannot explain why.

      Not sure it will really help but you can limit the number of DSNs returned by adding something like:

      if (numDataSources > 100) { break; }

      just after fDirection = SQL_FETCH_NEXT. If you restrict the number returned and the crash goes away you might be able to identify the entry that causes corruption.

        Ok. 280 is the magic number. It does not crash with
        if (numDataSources > 280) { break; }.
        And it does crash if i change to
        if (numDataSources > 281) { break; }.
        (The first DSN actually has numDataSources == 0).

        Update:

        There is nothing wrong with the next DSN, when i go to 281 the next one is still retrieved (like with all 310 entries) but it crashes still.

        The last lines of the output are in that case (before crashing):

        (I added "numDataSources" in the output as you can see:)
        /(276)/, /DF203BPA/ (8), /IBM DB2 ODBC DRIVER - DB2RTCL9N/ (31) /(277)/, /DF203BPE/ (8), /IBM DB2 ODBC DRIVER - DB2RTCL9N/ (31) /(278)/, /DF203BS/ (7), /IBM DB2 ODBC DRIVER - DB2RTCL9N/ (31) /(279)/, /DF203BPM/ (8), /IBM DB2 ODBC DRIVER - DB2RTCL9N/ (31) /(280)/, /DF203CEI/ (8), /IBM DB2 ODBC DRIVER - DB2RTCL9N/ (31) /(281)/, /DF203CMN/ (8), /IBM DB2 ODBC DRIVER - DB2RTCL9N/ (31)

        I am now thinking hard about this line in "ODBC.xs":

        ST(numDataSources++) = newSVpv(dsn, dsn_length+9 /* strlen("dbi:ODBC:") */ );

        Not sure if this always does what one expects on first glance. I am refering to the left side of the "=".

        Ok. I'm playing with that now. It works without crash(!) for 10 and 100. I am testing further.

        I did notice that i'm getting this warning though on the "dmake"(probably have overlooked that yesterday):

        dbdimp.c: In function 'odbc_db_STORE_attrib': dbdimp.c:4677:22: warning: cast to pointer from integer of different s +ize [-Wint-to-pointer-cast] dbdimp.c:4679:22: warning: cast to pointer from integer of different s +ize [-Wint-to-pointer-cast] dbdimp.c:4937:18: warning: cast to pointer from integer of different s +ize [-Wint-to-pointer-cast] dbdimp.c:4942:18: warning: cast to pointer from integer of different s +ize [-Wint-to-pointer-cast] dbdimp.c:4962:27: warning: cast to pointer from integer of different s +ize [-Wint-to-pointer-cast]

        Could be interesting.