[fpc-pascal] Firebird stored procedure exceptions generate access violation

Sun Jun 6 15:40:40 CEST 2010

On 5-6-2010 10:47, Michael Van Canneyt wrote:
> It might be worth putting all parameters in a record definition and pass
> the
> record to your function. That makes the procedure declaration somewhat more
> manageable and understandable. (and definitely more efficent as well).

Progress!

As you suggested, I've converted the code to use a record when passing
parameters (fields) to the procedure that calls the insert stored
procedure on Firebird.

See http://bitbucket.org/jb/flocate/changesets
commit 60:  	 9f6694fd910f
(To download: click on the commit message; you get a new page; top right
of screen: get source)

(The UDF that used to be on the firebird server has also been gone since
revision 59).

Now running
Free Pascal Compiler version 2.4.1 [2010/06/06] for x86_64

1. Compiling for 32 bit:
ppc386.exe flocate.lpr -b -FUoutput\i386-win32\ -FEoutput\i386-win32\ -g
-gh -gl -O- -vewnh -TWIN32

2. Compiling for 64 bit:
fpc flocate.lpr -b -FUoutput\x86_64-win64\ -FEoutput\x86_64-win64\ -g
-gh -gl -O- -vewnh

3. Running the 32 bit code:
output\i386-win32\flocate c:\windows\system32 1>test32.txt 2>test32err.txt

(In between: delete all table data using a stored procedure: EXECUTE
PROCEDURE CLEARALLDATA; COMMIT; )

4. Running the 64 bit code:
output\x86_64-win64\flocate c:\windows\system32 1>test64.txt 2>test64err.txt

Results:
32 bit:
Debug output shows no memory leaks:
Heap dump by heaptrc unit
392010 memory blocks allocated : 24734813/25968016
392010 memory blocks freed     : 24734813/25968016
0 unfreed memory blocks : 0
True heap size : 2457600 (160 used in System startup)
True free heap : 2457440

The insert code does bomb on a file:
Debug: 6-6-2010 14:56:03: Database error running insert query (filename:
<a filename>). Database error message:  : Execute :
 -Malformed string; Database error code: 335544849
... and it rolls back the transaction as expected.
Probably some character set issue as I had set the database character
set to UTF8; will set it to none next time...

64 bit:
Debut output shows lots of memory leaks:
Heap dump by heaptrc unit
2282244 memory blocks allocated : 700848239/714843280
2178376 memory blocks freed     : 687897476/701626320
103868 unfreed memory blocks : 12950763
True heap size : 31457280 (224 used in System startup)
True free heap : 1506976
Should be : 4944992
Call trace for block $00000000060BCF60 size 31
  $0000000100045146  TDIRECTORYENTRY__GETEXEINFO,  line 403 of
directoryentry.pp
  $0000000100046150  TDIRECTORYENTRY__READINFO,  line 544 of
directoryentry.pp
  $0000000100046D68  TDIRECTORYENTRY__CREATE,  line 781 of directoryentry.pp
  $000000010003E117  TFILESEARCH__ADDFILETORESULT,  line 210 of search.pp
  $000000010003ECFE  TFILESEARCH__SEARCHPERFILTER,  line 321 of search.pp
  $000000010003F003  TFILESEARCH__SEARCH,  line 356 of search.pp
  $0000000100001FBF  FLOCATE__DORUN,  line 245 of flocate.lpr
  $000000010003C938
Call trace for block $00000000060C0E70 size 53
  $00000001000450D7  TDIRECTORYENTRY__GETEXEINFO,  line 401 of
directoryentry.pp
  $0000000100046150  TDIRECTORYENTRY__READINFO,  line 544 of
directoryentry.pp
  $0000000100046D68  TDIRECTORYENTRY__CREATE,  line 781 of directoryentry.pp
  $000000010003E117  TFILESEARCH__ADDFILETORESULT,  line 210 of search.pp
  $000000010003ECFE  TFILESEARCH__SEARCHPERFILTER,  line 321 of search.pp
  $000000010003F003  TFILESEARCH__SEARCH,  line 356 of search.pp
  $0000000100001FBF  FLOCATE__DORUN,  line 245 of flocate.lpr
  $000000010003C938

The 64 bit code does return a lot of files from the database (though
it's missing e.g. cmd.exe which I'll have to look into).
It doesn't crash on the file it crashed on in my original post, possibly
because of cleaning the database?

Test run conclusion: same code, different amount of bits=> different
results.
I suspect the EXIF code I used may be sensitive to variable type sizes
etc. But I'm too much of a newbie to tell.

In any case, the access violation that used to be there doesn't happen
any more.

To find out how fpc deals with custom Firebird exceptions, I modified my
stored procedure to always call a custom exception regardless of input.
And there we go again:
Debug: 6-6-2010 15:21:14: Error running insert query (filename:
directoryentry.pp.i). Technical details: Access violation

Debugging in 64 bit:
GNU gdb 6.7.50.20080109-cvs
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-mingw32"...

warning: A handler for the OS ABI "Cygwin" is not built into this
configuration
of GDB.  Attempting to continue with the default i386:x86-64 settings.
(gdb) break fpc_raiseexception
Cannot access memory at address 0xc800
(gdb) run
...... debug output....
Program received signal SIGSEGV, Segmentation fault.
0x000000010000ad7d in FINALIZE$_DATEUTILS ()
(gdb) backtrace
#0  0x000000010000ad7d in FINALIZE$_DATEUTILS ()
#1  0x0000000001153640 in ?? ()
#2  0x000000000110b950 in ?? ()
#3  0x000000000110b950 in ?? ()
#4  0x000000010000715c in FINALIZE$_DATEUTILS ()
#5  0x0000000000010a70 in ?? ()
#6  0x0000000077488f15 in ?? ()
#7  0x0000000000010000 in ?? ()
#8  0x0000000001153640 in ?? ()
#9  0x000000000102ef10 in ?? ()
#10 0x0000000100052f80 in FINALIZE$_DATEUTILS ()
#11 0x0000000000000000 in ?? ()

Debugging in 32 bit:
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32"...
(gdb) break fpc_raiseexception
Breakpoint 1 at 0x40a9c6
...... debug output....
Breakpoint 1, 0x0040a9c6 in fpc_raiseexception ()
(gdb) backtrace
#0  0x0040a9c6 in fpc_raiseexception ()
#1  0x0043d284 in
IBCONNECTION_TIBCONNECTION_$__CHECKERROR$ANSISTRING$PISC_STATUS ()
#2  0x0043e9ca in
IBCONNECTION_TIBCONNECTION_$__EXECUTE$TSQLCURSOR$TSQLTRANSACTION$TPARAMS ()
#3  0x0043ac1a in SQLDB_TCUSTOMSQLQUERY_$__EXECUTE ()
#4  0x0043b7d9 in SQLDB_TCUSTOMSQLQUERY_$__EXECSQL ()
#5  0x00437e51 in TFLOCATEDB__SAVEDIRECTORYENTRY (INSERTFIELDS=
      {COMPUTERNAME = 0x1649fb8 "MARVIN", DATEACCESSED =
40335.475694444445, DATECREATED = 40335.475694444445, DATEMODIFIED =
39282.142569444448, EXECOMPANY = 0x0, EXECOPYRIGHT = 0x0, EXEDESCRIPTION
= 0x0, EXEFILEVERSION = 0x0, EXEINTERNALNAME = 0x0, EXEORIGINALFILENAME
= 0x0, EXEPRODUCTNAME = 0x0, EXEPRODUCTVERSION =
0x0, EXIFAPERTURE = 0x0, EXIFARTIST = 0x0, EXIFCOMPRESSEDBPP = 0x0,
EXIFCOPYRIGHT = 0x0, EXIFDATETIME = -693593, EXIFDATETIMEDIGITIZED =
-693593, EXIFDATETIMEORIGINAL = -693593, EXIFEXPOSURE = 0x0,
EXIFEXPOSUREPROGRAM = 0x0, EXIFFLASH = 0x0, EXIFFSTOPS = 0x0,
EXIFIMAGEDESCRIPTION = 0x0, EXIFISO = 0, EXIFLIGHTSOURCE = 0x0, EXIFMAKE
= 0x0, EXIFMAXAPERTURE = 0x0, EXIFMETERINGMETHOD = 0x0, EXIFMETERINGMODE
= 0x0, EXIFMODEL = 0x0, EXIFORIENTATION = 0x0, EXIFPIXELXDIMENSION = 0,
EXIFPIXELYDIMENSION = 0, EXIFSHUTTERSPEED = 0x0, EXIFSOFTWARE = 0x0,
EXIFUSERCOMMENTS = 0x0, EXIFXRESOLUTION = 0, EXIFYRESOLUTION = 0,
FILEDESCRIPTION = 0x0, FILENAME = 0x164a078 "fbintl.conf", FILEPATH =
0x16d11e8 "C:\\Users\\jimbeam\\My
Documents\\Lazarus\\flocate\\output\\i386-win32\\intl\\", FILESIZE =
6656, FILETYPE = 0x164d198 "other", MD5HASH = 0x16acbf0
"0304b1526d4db539276853d987159277", MP3ALBUM = 0x0, MP3ARTIST = 0x0,
MP3COMMENT = 0x0, MP3GENRE = 0x0, MP3TITLE = 0x0, MP3TRACK = 0, MP3YEAR
= 0}, this=0x1651f98)
    at flocatedb.pp:484
#6  0x00432cd7 in TDIRECTORYENTRYLIST__SAVETODATABASE (this=0x1649ef0)
    at directoryentrylist.pp:236
#7  0x0042f359 in TFILESEARCH__SAVETODATABASE (this=0x1649e90)
    at search.pp:245
#8  0x00401e62 in TFLOCATE__DORUN (this=0x1660fd8) at flocate.lpr:246
#9  0x0042dd54 in CUSTAPP_TCUSTOMAPPLICATION_$__RUN ()
#10 0x004025ec in main () at flocate.lpr:329

Seems like fpc simply doesn't know how to deal with those exceptions???

-- 
Regards,

jb