Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2006-11

How can i detect what cause the problem

5 messages · 4 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Gabor Boros

Hi,

I have a Symbol mobile device with an integrated barcode scanner. The scanner's API in C and I cannot use every API calls.

An example: The problem appears in the
ScanBuffer:=SCAN_AllocateBuffer(TRUE,dwScanSize);
line (see the test app below).
If I run in GDB the error message is:

warning: Prefetch Abort: Thread=8dcfe8dc Proc=8c329ab0 'project1.exe' warning: AKY=00004001 PC=00000000 RA=00011338 BVA=00000000 FSR=000004f0

Program received signal SIGSEGV, Segmentation fault. 0x00000000 in ?? ()

The test app is:

program test;
{$apptype console}
{$PACKRECORDS C}
uses Windows, dynlibs;
const
   MAx_SRC=32;
   dwScanSize:DWORD=7095;
type
   STRUCT_INFO=record
     dwAllocated:DWORD;
     dwUsed:DWORD;
   end;
   LABELTYPE = DWORD;
   LPSCAN_BUFFER = ^SCAN_BUFFER;
   SCAN_BUFFER=record
     StructInfo:STRUCT_INFO;
     dwDataBuffSize:DWORD;
     dwOffsetDataBuff:DWORD;
     dwDataLength:DWORD;
     dwTimeout:DWORD;
     dwStatus:DWORD;
     bText:BOOL;
     dwLabelType:LABELTYPE;
     dwRequestID:DWORD;
     TimeStamp:SYSTEMTIME;
     dwDirection:DWORD;
     szSource:array[0..MAx_SRC-1] of TCHAR;
     blsMultiPart:BOOL;
     dwScanID:DWORD;
     dwBarcodeID:DWORD;
     dwNumRemaining:DWORD;
     dwOffsetAuxDataBuff:DWORD;
     dwAuxDataLength:DWORD;
   end;
   T_SCAN_AllocateBuffer = function
(bText:BOOL;dwSize:DWORD):LPSCAN_BUFFER; cdecl;
var
   SCAN_AllocateBuffer: T_SCAN_AllocateBuffer;
   DLL_Handle:TLibHandle;
   ScanBuffer:LPSCAN_BUFFER;
begin
   DLL_Handle:=LoadLibrary('SCNAPI32.DLL');
   Pointer(SCAN_AllocateBuffer):=GetProcedureAddress(DLL_Handle,
'SCAN_AllocateBuffer');
   ScanBuffer:=SCAN_AllocateBuffer(TRUE,dwScanSize);
   UnloadLibrary(DLL_Handle);
end.

Thanks!

Gabor

Reply by email

Felipe Monteiro de Carvalho
to Gabor Boros

Can you show us the c declaration of the function you are calling? It should be on a .h file.

Also, you should put an way to verify if the calls are working, like:

    DLL_Handle:=LoadLibrary('SCNAPI32.DLL');
    if DLL_Handle = nil then raise EException.Create('Could not load library');
    Pointer(SCAN_AllocateBuffer):=GetProcedureAddress(DLL_Handle,
 'SCAN_AllocateBuffer');
    if Pointer(SCAN_AllocateBuffer) = nil then raise
EException.Create('Could not load procedure');

One possibility is that this C library uses name mangling, and the function has a different name from the canonical one. You can check all function names exported by the function using this software:

http://wiki.lazarus.freepascal.org/Libview

Felipe Monteiro de Carvalho

Reply by email

Michael Van Canneyt
to Gabor Boros: I have a Symbol mobile device with an integrated barcode scanner. The scanner's API in C…
Gabor Boros wrote 61 lines
Hi, I have a Symbol mobile device with an integrated barcode scanner. The scanner's API in C and I cannot use every API calls. An example: The problem appears in the ScanBuffer:=SCAN_AllocateBuffer(TRUE,dwScanSize); line (see the test app below). If I run in GDB the error message is: warning: Prefetch Abort: Thread=8dcfe8dc Proc=8c329ab0 'project1.exe' warning: AKY=00004001 PC=00000000 RA=00011338 BVA=00000000 FSR=000004f0 Program received signal SIGSEGV, Segmentation fault. 0x00000000 in ?? () The test app is: program test; {$apptype console} {$PACKRECORDS C} uses Windows, dynlibs; const MAx_SRC=32; dwScanSize:DWORD=7095; type STRUCT_INFO=record dwAllocated:DWORD; dwUsed:DWORD; end; LABELTYPE = DWORD; LPSCAN_BUFFER = ^SCAN_BUFFER; SCAN_BUFFER=record StructInfo:STRUCT_INFO; dwDataBuffSize:DWORD; dwOffsetDataBuff:DWORD; dwDataLength:DWORD; dwTimeout:DWORD; dwStatus:DWORD; bText:BOOL; dwLabelType:LABELTYPE; dwRequestID:DWORD; TimeStamp:SYSTEMTIME; dwDirection:DWORD; szSource:array[0..MAx_SRC-1] of TCHAR; blsMultiPart:BOOL; dwScanID:DWORD; dwBarcodeID:DWORD; dwNumRemaining:DWORD; dwOffsetAuxDataBuff:DWORD; dwAuxDataLength:DWORD; end; T_SCAN_AllocateBuffer = function (bText:BOOL;dwSize:DWORD):LPSCAN_BUFFER; cdecl;

I would be very surprised to see that a Windows DLL uses cdecl; as calling convention. Try changing this to

  T_SCAN_AllocateBuffer = function (bText:BOOL;dwSize:DWORD):LPSCAN_BUFFER; stdcall;

Michael.

Reply by email

Gabor Boros
to Felipe Monteiro de Carvalho: Can you show us the c declaration of the function you are calling? It should be on a .h…

Many thanks Felipe, the problem is the exported name(s). The exported names is SCAN_AllocateBuffer_A and SCAN_AllocateBuffer_W.

Thanks again!

Gabor

Felipe Monteiro de Carvalho írta:

Show quoted text 22 lines
Can you show us the c declaration of the function you are calling? It should be on a .h file. Also, you should put an way to verify if the calls are working, like: DLL_Handle:=LoadLibrary('SCNAPI32.DLL'); if DLL_Handle = nil then raise EException.Create('Could not load library'); Pointer(SCAN_AllocateBuffer):=GetProcedureAddress(DLL_Handle, 'SCAN_AllocateBuffer'); if Pointer(SCAN_AllocateBuffer) = nil then raise EException.Create('Could not load procedure'); One possibility is that this C library uses name mangling, and the function has a different name from the canonical one. You can check all function names exported by the function using this software: http://wiki.lazarus.freepascal.org/Libview

Reply by email

Daniel Franzini
to Gabor Boros

this happens because windows API code usually have two versions: an Ascii version where chars are 8-bit ASCII (with the suffix A, and used mainly in 9x code) and other where the chars are 2-byte unicode chars with the W suffix, used mainly in 2000/XP stuff (guess W means wide in the sense of widestring)

Gabor Boros wrote 36 lines
Many thanks Felipe, the problem is the exported name(s). The exported names is SCAN_AllocateBuffer_A and SCAN_AllocateBuffer_W. Thanks again! Gabor Felipe Monteiro de Carvalho írta: > Can you show us the c declaration of the function you are calling? It > should be on a .h file. > > Also, you should put an way to verify if the calls are working, like: > > DLL_Handle:=LoadLibrary('SCNAPI32.DLL'); > > if DLL_Handle = nil then raise EException.Create('Could not load > library'); > > Pointer(SCAN_AllocateBuffer):=GetProcedureAddress(DLL_Handle, > 'SCAN_AllocateBuffer'); > > if Pointer(SCAN_AllocateBuffer) = nil then raise > EException.Create('Could not load procedure'); > > One possibility is that this C library uses name mangling, and the > function has a different name from the canonical one. You can check > all function names exported by the function using this software: > > http://wiki.lazarus.freepascal.org/Libview > _______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Daniel "Let us change our traditional attitude to the construction of programs. Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do." (Donald Knuth) "Yes, technogeeks can be funny, even if only to each other." ( http://www.boogieonline.com/revolution/science/humor/)" "Man is driven to create; I know I really love to create things. And while I'm not good at painting, drawing, or music, I can write software." (Yukihiro Matsumoto, a.k.a. ``Matz'')

Reply by email