How can i detect what cause the problem

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

How can i detect what cause the problem

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
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: How can i detect what cause the problem

Felipe Monteiro de Carvalho
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
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: How can i detect what cause the problem

michael.vancanneyt
In reply to this post by Gabor Boros


On Tue, 14 Nov 2006, Gabor Boros wrote:

> 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.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: How can i detect what cause the problem

Gabor Boros
In reply to this post by Felipe Monteiro de Carvalho
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  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: How can i detect what cause the problem

Daniel Franzini
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)

On 11/14/06, Gabor Boros <[hidden email]> wrote:
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  -  [hidden email]
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'')
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal