[fpc-pascal] C++ > C wrapper callback > Pascal Continues UPDATE

[Tomas Hajny]

From: "Urbansound" <urbansound at sbcglobal.net>
To: <fpc-pascal at lists.freepascal.org>
Sent: Wednesday, July 27, 2005 11:05 PM
Subject: C++ > C wrapper callback > Pascal Continues

 .
 .
>> 3) The API is multi-threaded, having dl'd a thread monitor, showing as
>> many as 5 threads spawened to the API and accompanied executable.  As
>> well, a call back occurs by default from the API, at runtime, suggesting
>> it fires off a single dummy callback event.

OK. As long as the callback is only called in one thread (the same one
which passed the callback address as confirmed in your message below),
number of other threads spawned by the C++ code shouldn't really matter.


 .
 .
>> //------- Current function model below here
>>
>> function L1_Callback(quote : pointer) : integer; stdcall; export;
>> var
>>    bid_price : single = 0.0;
>>    s : ansistring = '';
>> begin
>>    SendMessage(listbox, LB_ADDSTRING, 0, longint(Pchar('L1 Callback')));
>>        // -- either commented below will cause crash
>>    //SendMessage(listbox, LB_ADDSTRING, 0, longint(Get_secsym(quote)));
>>    //bid_price := Get_l1_BidPrice(quote);
>>    s := FloatToStr(bid_price);
>>    SendMessage(ListBox,LB_ADDSTRING,0,Longint(pointer(s)))
>> end;
 .
 .
> Among our C equivelent of the Pascal program, we did the following, which
> confirms that the C+ callback and Pascal, are on the same, single thread,
> which was confirmed with a thread monitoring tool during operation.  (See
> comment at bottom).
 .
 .
> Given that an equivelent C program, (built by modifying the Pascal program
> to suit C syntax/method), runs without a problem and yet there is no
> evident
> reason code-wise for the problem, what is the next step in resolving the
> matter.  I can use GDB, though I am new to it, as of this issue.  If
> someone
> is willing to give me a guide on what command/data gdb can afford us, I'd
> certainly make the effort here, unless there are other suggestions?  This
> is
> fpc 2.00, so I'm current w/stable.

I'm afraid I'm not the right one to teach GDB commands. ;-) However, I
believe that setting up a HW breakpoint to the address of the Pascal
callback ("hbreak L1_CALLBACK"?) should indeed allow you to check why it
crashed (e.g. "bt" command in GDB should show you where exactly the crash
happens which in turn should help to find the reason). You should compile
your program with debugging enabled RTL, though. Based on the particular
error, I'd suggest to watch the stack while tracing through the code,
because my guess is that a thrashed stack directs you to an improper
address.

Tomas