Announcement

Collapse
No announcement yet.

my dll causes windows fault

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • my dll causes windows fault

    I created a dll to convert a date string into the unique day number. I use this dll in several programs without any problems. However, one program causes the "windows must close" message after running the program 2 or three times in succession without closing the program. The details in the windows error seems to point to my dll.



    This is the declare I use for the dll.

    DECLARE FUNCTION JULIANDLL LIB "Julian.dll" ALIAS "Juliandate" (BYREF userdate AS STRING) AS LONG

    and here is the dll code

    Code:
    #COMPILE DLL
    #DIM ALL
    
    %USEMACROS = 1
    #INCLUDE "Win32API.inc"
    
    GLOBAL ghInstance AS DWORD
    
    
    
    
    
    
    
    '-------------------------------------------------------------------------------
    ' Main DLL entry point called by Windows...
    '
    FUNCTION LIBMAIN (BYVAL hInstance   AS LONG, _
                      BYVAL fwdReason   AS LONG, _
                      BYVAL lpvReserved AS LONG) AS LONG
    
        SELECT CASE fwdReason
    
        CASE %DLL_PROCESS_ATTACH
            'Indicates that the DLL is being loaded by another process (a DLL
            'or EXE is loading the DLL).  DLLs can use this opportunity to
            'initialize any instance or global data, such as arrays.
    
            ghInstance = hInstance
    
            FUNCTION = 1   'success!
    
            'FUNCTION = 0   'failure!  This will prevent the EXE from running.
    
        CASE %DLL_PROCESS_DETACH
            'Indicates that the DLL is being unloaded or detached from the
            'calling application.  DLLs can take this opportunity to clean
            'up all resources for all threads attached and known to the DLL.
    
            FUNCTION = 1   'success!
    
            'FUNCTION = 0   'failure!
    
        CASE %DLL_THREAD_ATTACH
            'Indicates that the DLL is being loaded by a new thread in the
            'calling application.  DLLs can use this opportunity to
            'initialize any thread local storage (TLS).
    
            FUNCTION = 1   'success!
    
            'FUNCTION = 0   'failure!
    
        CASE %DLL_THREAD_DETACH
            'Indicates that the thread is exiting cleanly.  If the DLL has
            'allocated any thread local storage, it should be released.
    
            FUNCTION = 1   'success!
    
            'FUNCTION = 0   'failure!
    
        END SELECT
    
    
     END FUNCTION
    
     FUNCTION Juliandate ALIAS "Juliandate" (BYREF userdate AS STRING) EXPORT AS LONG
    
    LOCAL MONTH ,DAY ,YEAR,ya,cf,yf,mf,century AS LONG
    LOCAL MJULIAN AS LONG
    LOCAL m,d,y,jdn,a  AS LONG
    LOCAL UD() AS STRING,x AS LONG
    x = PARSECOUNT(USERDATE,ANY "./-")
    REDIM Ud$(1 TO x)
    PARSE userdate,Ud$(),ANY",./-"
    
    m = VAL(Ud$(1)):d = VAL(Ud$(2)) :y = VAL(Ud$(3))
    month = VAL(Ud$(1)):day = VAL(Ud$(2)) :year = VAL(Ud$(3))
    IF year => 80 AND year <100    THEN year = year  +1900
    IF year <80 THEN year = year + 2000
    
        a = (14 - month)\12
        y = year + 4800 -a
        m = month +(12*a) - 3
        JDN = d +((153*m)+2)\5 + (365*y) + (y\4) - (y\100) +(y\400) - 32045
     '   END IF
    FUNCTION = jdn
    END FUNCTION
    I have written test code to verify that all the date strings sent to dll are correct. All dates are generated programatically in another program.

    I can usually fix errors with the PB tools, but "trace" and "debug display" show no errors. If someone would look at the compilable code in the zip file, I would certainly appreciate any help.

    Thanks,

    John Tate
    Attached Files

  • #2
    Change byref to byval.
    How did you come up with byref..?

    Returning non-zero in the libmain is required.
    hellobasic

    Comment


    • #3
      I changed the byref to byval and I can run it twice in the IDE, but get the error the first time when running it from a menu that shells the calling exe file.
      Thanks, Edwin for helping.

      It is obvious I do not know what I am doing with dlls.


      John Tate

      Comment


      • #4
        I copied the code from my dll into a function that I used in then source program. I can now see that I have an error 9 showing up. I will search for the source of that error, which debug display says comes after execution of my new date conversion function.
        It seems that the error was not so much in the dll itself.

        I will pursue it in the morning. It is 12:40 pm in Oregon.

        John Tate

        Comment


        • #5
          >It seems that the error was not so much in the dll itself.

          Great 'Real Life' demonstration that when memory corruption is involved, the error was not necessarily made immediately preceding the time of death.

          PS:
          It is obvious I do not know what I am doing with dlls.
          You're doing fine.

          Functions in DLLs are just like inline functions. The only difference is you need a DECLARE statement instead of an #INCLUDE file in the calling module.*



          MCM
          * Not including compiler-specific restrictions on inter-module validity of certain reference objects or handles such as DDT-created controls or file handles. You mileage may vary. Winner is responsible for all taxes. Void where prohibited
          Michael Mattias
          Tal Systems (retired)
          Port Washington WI USA
          [email protected]
          http://www.talsystems.com

          Comment


          • #6
            Here is what I have found out so far. It is the assignment statements in the dll where I assign val(array var) to a long var.
            I have been using parse(string, any char) to fill my array with the month,day and year from the date string. If I use parse$ only, I get no error 9.
            Strange. What am I doing wrong?

            John Tate

            Code:
            #COMPILE DLL
            #DIM ALL
            
            %USEMACROS = 1
            #INCLUDE "Win32API.inc"
            
            GLOBAL ghInstance AS DWORD
            
            
            
            
            
            
            
            '-------------------------------------------------------------------------------
            ' Main DLL entry point called by Windows...
            '
            FUNCTION LIBMAIN (BYVAL hInstance   AS LONG, _
                              BYVAL fwdReason   AS LONG, _
                              BYVAL lpvReserved AS LONG) AS LONG
            
                SELECT CASE fwdReason
            
                CASE %DLL_PROCESS_ATTACH
                    'Indicates that the DLL is being loaded by another process (a DLL
                    'or EXE is loading the DLL).  DLLs can use this opportunity to
                    'initialize any instance or global data, such as arrays.
            
                    ghInstance = hInstance
            
                    FUNCTION = 1   'success!
            
                    'FUNCTION = 0   'failure!  This will prevent the EXE from running.
            
                CASE %DLL_PROCESS_DETACH
                    'Indicates that the DLL is being unloaded or detached from the
                    'calling application.  DLLs can take this opportunity to clean
                    'up all resources for all threads attached and known to the DLL.
            
                    FUNCTION = 1   'success!
            
                    'FUNCTION = 0   'failure!
            
                CASE %DLL_THREAD_ATTACH
                    'Indicates that the DLL is being loaded by a new thread in the
                    'calling application.  DLLs can use this opportunity to
                    'initialize any thread local storage (TLS).
            
                  '  FUNCTION = 1   'success!
            
                    'FUNCTION = 0   'failure!
            
                CASE %DLL_THREAD_DETACH
                    'Indicates that the thread is exiting cleanly.  If the DLL has
                    'allocated any thread local storage, it should be released.
            
                 '   FUNCTION = 1   'success!
            
                    'FUNCTION = 0   'failure!
            
                END SELECT
            
            
             END FUNCTION
            
             FUNCTION Juliandate ALIAS "Juliandate" (BYVAL userdate AS STRING) EXPORT AS LONG
            
            LOCAL MONTH ,DAY ,YEAR AS LONG
            LOCAL m,d,y,jdn,a  AS LONG
            LOCAL UD() AS STRING,x AS LONG
            'x = PARSECOUNT(USERDATE,ANY "./-")
            'REDIM Ud(1 TO x)
            'PARSE userdate,Ud(),ANY ",./-"
            'all ok to here
            'the assignment statements below cause the error 9
            'm = VAL(Ud(1))
            'd = VAL(Ud(2))
            'y = VAL(Ud(3))
            'month = VAL(Ud$(1)):day = VAL(Ud$(2)) :year = VAL(Ud$(3))
            
            'using the parse$ causes no error 9
            month = VAL(PARSE$(userdate,ANY ",./-",1))
            day = VAL(PARSE$(userdate,ANY ",./-",2))
            year = VAL(PARSE$(userdate,ANY ",./-",3))
            
            IF year => 80 AND year <100    THEN year = year  +1900
            IF year <80 THEN year = year + 2000
            
                a = (14 - month)\12
                y = year + 4800 -a
                m = month +(12*a) - 3
                JDN = day +((153*m)+2)\5 + (365*y) + (y\4) - (y\100) +(y\400) - 32045
             '   END IF
            FUNCTION = jdn
            END FUNCTION

            Comment


            • #7
              Code:
              'x = PARSECOUNT(USERDATE,ANY "./-")
              'REDIM Ud(1 TO x)
              'PARSE userdate,Ud(),ANY ",./-"
              Your parse strings are different: one includes comma, one does not. If the input uses comma as a delimiter, the array will not be large enough to hold all the elements and you will commit an array bounds violation (error 9).

              Good place to take out insurance against mistyped "magic numbers" ...

              Code:
                LOCAL Delim  AS STRING 
                Delim = ",./-" 
              ...
                X        =  PARSECOUNT (UserDate, ANY Delim) 
                REDIM     UD (1 TO X) 
                PARSE     UserDate, UD(), ANY Delim

              MCM
              Last edited by Michael Mattias; 24 May 2009, 09:32 AM.
              Michael Mattias
              Tal Systems (retired)
              Port Washington WI USA
              [email protected]
              http://www.talsystems.com

              Comment


              • #8
                Thanks, Michael. I feel really stupid! I thought I was a better programmer than that!!
                In any case, that is why I did not cry "bug", because my problems are 99.99% my programming errors.

                Even though I solved the problem by using parse$, I still wanted to know why it would not work using Parse.

                Thanks again,

                John Tate

                Comment


                • #9
                  that is why I did not cry "bug", because my problems are 99.99% my programming errors.
                  Oh come now, don't you know that "It could NOT be my code, it MUST be a PB problem???"

                  Honestly though, its nice to see that someone can admit their mistakes, and not blame it on the compiler.
                  Engineer's Motto: If it aint broke take it apart and fix it

                  "If at 1st you don't succeed... call it version 1.0"

                  "Half of Programming is coding"....."The other 90% is DEBUGGING"

                  "Document my code????" .... "WHYYY??? do you think they call it CODE? "

                  Comment


                  • #10
                    Some day I would like to see a statistic from all the years of support calls taken by PowerBASIC: "Percent of calls claiming compiler problem which turned out to be user problem rather than compiler problem."

                    One, two percent tops is where I'd put my money.

                    There are some bugs to be sure, but not very many. Compiler problem is the last place to look for program problems.
                    Michael Mattias
                    Tal Systems (retired)
                    Port Washington WI USA
                    [email protected]
                    http://www.talsystems.com

                    Comment


                    • #11
                      Originally posted by Michael Mattias View Post
                      Some day I would like to see a statistic from all the years of support calls taken by PowerBASIC: "Percent of calls claiming compiler problem which turned out to be user problem rather than compiler problem."

                      One, two percent tops is where I'd put my money.

                      There are some bugs to be sure, but not very many. Compiler problem is the last place to look for program problems.
                      Must be springtime in Minnesota. M's getting mellow again. {grin}

                      (I know, I know. He lives in Wisconsin but that's not as alliteral.)

                      =========================================
                      "My advice to you is get married:
                      if you find a good wife you'll be happy;
                      if not, you'll become a philosopher."
                      Socrates (470-399 B.C.)
                      =========================================
                      It's a pretty day. I hope you enjoy it.

                      Gösta

                      JWAM: (Quit Smoking): http://www.SwedesDock.com/smoking
                      LDN - A Miracle Drug: http://www.SwedesDock.com/LDN/

                      Comment


                      • #12
                        I'm not mellowing out at all; I have been saying this for years.

                        But if it makes you feel better....

                        "A signicantly higher rate should be expected if one includes as compiler problems user mistakes directly attributable to inaccurate, incomplete, hard-to-find or misleading documentation."

                        Happy now?

                        (I've been saying that for years, too.)

                        MCM
                        Michael Mattias
                        Tal Systems (retired)
                        Port Washington WI USA
                        [email protected]
                        http://www.talsystems.com

                        Comment

                        Working...
                        X