Sign in Join

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

Mailing lists / fpc-pascal / 2004-06

parameter is 0x0 on callback

18 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

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

Marc Santhoff

Hello,

I've used the stuff following with fpc 1.0.10 and it worked fine, now with 1.9.2 the argument is set to zero:

- a GTK+ 1.2 program)
- a dialog has a pointer to a 'cdecl'ed callback procedure:

<code>
...
src := TCustomer(datasrc.Items[selCursor]);
{$ifdef debug} writeln(src.asCSV); {$endif}

{ propagate selected entry }
cbPropagate(src);
...
</code>

the debug output is okay, public string fields are filled. There the field 'Name' is accessed.

This is where 'cbPropagate' goes to:

<code>
procedure setCustDataCallback(data: TCustomer); cdecl;
begin
	writeln('Name is '+_data.Name);
...
</code>

when trying to write out the TCustomer field 'Name' declared as an AnsiString, the debugger tells me 'data' points to zero (0x0).

Can someone please explain to me what's happening here? And why it worked fine on the 1.0.10 version of fpc?

TIA,
Marc

Marc Santhoff
to Marc Santhoff

Hi again,

the problem seems to occur any time I try to access (unit global) variables in a cdecl-ed procedure or function, too. They are simply invisible in the debugger.

What am I doing wrong here?

Marc

Peter Vreman
to Marc Santhoff
Show quoted text 7 lines
Hi again, the problem seems to occur any time I try to access (unit global) variables in a cdecl-ed procedure or function, too. They are simply invisible in the debugger. What am I doing wrong here?

Try the 1.9.4 release, there are fixes in the debuginfo generation

Peter Vreman
to Marc Santhoff: I've used the stuff following with fpc 1.0.10 and it worked fine, now with 1.9.2 the…
Show quoted text 34 lines
Hello, I've used the stuff following with fpc 1.0.10 and it worked fine, now with 1.9.2 the argument is set to zero: - a GTK+ 1.2 program) - a dialog has a pointer to a 'cdecl'ed callback procedure: <code> ... src := TCustomer(datasrc.Items[selCursor]); {$ifdef debug} writeln(src.asCSV); {$endif} { propagate selected entry } cbPropagate(src); ... </code> the debug output is okay, public string fields are filled. There the field 'Name' is accessed. This is where 'cbPropagate' goes to: <code> procedure setCustDataCallback(data: TCustomer); cdecl; begin writeln('Name is '+_data.Name); ... </code> when trying to write out the TCustomer field 'Name' declared as an AnsiString, the debugger tells me 'data' points to zero (0x0). Can someone please explain to me what's happening here?

Without a full (short) example we can't do anything.

And why it worked fine on the 1.0.10 version of fpc?

1.9.2 uses register calling by default.

Marc Santhoff
to Peter Vreman

Am Fr, den 04.06.2004 schrieb Peter Vreman um 08:46: [...]

Without a full (short) example we can't do anything.

See below, I've tried to cut down the size without loosing to much information this time ...

> And why it worked fine on the 1.0.10 version of fpc? 1.9.2 uses register calling by default.

I don't get that. Do you say it worked by accident?

The code:
------------------------
unit StateInput;

{$define debug}
interface

...
procedure setCustDataCallback(data: TCustomer); cdecl; ...

implementation
procedure setCustDataCallback(data: TCustomer); cdecl;
begin
	writeln('Name is '+_data.Name);
	with _data do begin
		if (Name  '') then gtk_entry_set_text(_me.entries[0], pchar(@Name));
		if (FirstName  '') then gtk_entry_set_text(_me.entries[1], pchar(@FirstName));
...
end;
procedure showCustomerBrowser(btn: pGtkButton; data: gpointer); cdecl;
var
	ds: TDataSource;
begin
	writeln('SI: showCustomerBrowser start');
	if not(DBMan=NIL) then ds := DBMan.customers else writeln('SI: DBMan=NIL!');
	br := TCustomerBrowser.create(ds, @setCustDataCallback);
	writeln('SI: browser created');
	br.execute;
end;

---------------------------------

unit CustomerBrowser;
type
	TPropagateCallback = procedure(data: TCustomer);
	TCustomerBrowser = class
	public
		dialog: pGtkWidget; { access for caller granted }
		constructor create(data: TDataSource; callback: TPropagateCallback);
		destructor destroy; override;
		function execute: boolean;
	private
		btnOkay: pGtkWidget;
		btnCancel: pGtkWidget;
		headline: pGtkWidget;
		scroll: pGtkWidget;
	    	list: pGtkWidget;
		procedure fillCustomerList(l: pGtkCList);
	end;
procedure onCustOkay(data : pGtkCList ); cdecl;
var	{ should be props, doesn't work with callbacks }
	cbPropagate	: TPropagateCallback;
...
implementation
constructor TCustomerBrowser.create(data: TDataSource; callback: TPropagateCallback);
begin
	inherited create;
	_creating := TRUE;
	cbPropagate := callback;
...
end;
procedure onCustOkay(data : pGtkCList ); cdecl;
var
	src: TCustomer;
	dlg: pGtkDialog;
	btnOk: pGtkWidget;
	(*towait, remain : timespec;*)
begin
	if (selCursor > -1) then begin
		{ fetch selected entry }
		selCursor := datasrc.indexOfID(selCursor);
		gtk_clist_set_auto_sort(data, FALSE);
		src := TCustomer(datasrc.Items[selCursor]);
		{$ifdef debug} writeln(src.asCSV); {$endif}
		{ propagate selected entry }
		cbPropagate(src);
		gtk_widget_destroy(_me);
...
end;

----------------------------

unit CommonTypes;
interface
...
type
	TCustomerClass = class of TCustomer;
	TCustomer = class(TStorable)
		Name: AnsiString;
		FirstName: AnsiString;
		Street: AnsiString;
		Zip: Ansistring;
		City: AnsiString;
...
		function asCSV: AnsiString; override;
		procedure fillFromCSV(csv: AnsiString); override;
		class function getHeaderString: AnsiString; override; { first line of CSV format }
	end;
const
	SEP: char = ';';
	QT: char = '"';
implementation

function TCustomer.asCSV: AnsiString;
begin

	result := 	IntToStr(ID) +
			SEP + QT + Name + QT +
			SEP + QT + FirstName + QT +
			SEP + QT + Street + QT +
			SEP + QT + ZIP + QT +
			SEP + QT + City + QT +
			SEP + QT + Phone + QT +

...

	{$ifdef debug}writeln('CT:customer.asCSV:'+result);{$endif}

end;
---------------------

I hope there is a solution. As written, the TCustomer item "src" should be handed over to the code calling the browser dialog and it's zero any time in the callback in the first unit.

Writing out it's content in the code that makes the call to the callback with "asCSV" works okay, the contained information is correct.

Marc

Peter Vreman
to Marc Santhoff
Show quoted text 10 lines
> Without a full (short) example we can't do anything. See below, I've tried to cut down the size without loosing to much information this time ... > > And why it worked fine on the 1.0.10 version of fpc? > > 1.9.2 uses register calling by default. I don't get that. Do you say it worked by accident?

Possibly, 1.0.10 uses a different calling convention that looks more like cdecl.

The code: ------------------------

Sorry, but is still useless because it can't be compiled. Only full working (easy to build and run) short examples help.

Try to isolate the problem in a smaller program.

Marc Santhoff
to Peter Vreman
Show quoted text 13 lines
>> Without a full (short) example we can't do anything. > > See below, I've tried to cut down the size without loosing to much > information this time ... > >> > And why it worked fine on the 1.0.10 version of fpc? >> >> 1.9.2 uses register calling by default. > > I don't get that. Do you say it worked by accident? Possibly, 1.0.10 uses a different calling convention that looks more like cdecl.

Maybe that was the cause for the un detectable 'internal error' problem with 1.01.10 that made me switch to 1.9 ...

Show quoted text 8 lines
> The code: > ------------------------ Sorry, but is still useless because it can't be compiled. Only full working (easy to build and run) short examples help. Try to isolate the problem in a smaller program.

Okay, I'm coming back on this asap.

Thank so far,
Marc

Peter Vreman
to Marc Santhoff
Here it is (as attachment, hopefully the list processor doesn't strip it off):

1.9.4 reports:

main192.pp(25,52) Error: Incompatible type for arg no. 1: Got "<address of procedure(TCustomer);CDecl>", expected "<procedure variable type of procedure(TCustomer);Register>"

Marc Santhoff
to Peter Vreman
Show quoted text 8 lines
> Here it is (as attachment, hopefully the list processor doesn't strip it > off): 1.9.4 reports: main192.pp(25,52) Error: Incompatible type for arg no. 1: Got "<address of procedure(TCustomer);CDecl>", expected "<procedure variable type of procedure(TCustomer);Register>"

Ah, I see. I'll change the declaration of the callback proc then.

I hope the version 1.9.4 is getting into the ports system of FreeBSD soon, I got the port yesterday which is (not that far behind ;).

Maybe I can use the Linux emulation and use 1.9.4/Linux for error detection immediately ...

Thank you very much, it helped a lot,
Marc

Marco van de Voort
to Marc Santhoff
Show quoted text 11 lines
> 1.9.4 reports: > > main192.pp(25,52) Error: Incompatible type for arg no. 1: Got "<address of > procedure(TCustomer);CDecl>", expected "<procedure variable type of > procedure(TCustomer);Register>" Ah, I see. I'll change the declaration of the callback proc then. I hope the version 1.9.4 is getting into the ports system of FreeBSD soon, I got the port yesterday which is (not that far behind ;).

Don't expect it too soon, it is quite some work, and worse, the time between committing and submitting is quite long on avg.

Maybe I can use the Linux emulation and use 1.9.4/Linux for error detection immediately ...

Or simply use the 1.9.4/freebsd release?

Marc Santhoff
to Marc Santhoff: Ah, I see. I'll change the declaration of the callback proc then. I hope the version…

Hi again,

oncemore for the sake of completeness:

The 1.9.2 version of fpc is buggy on FreeBSD.

I get various problems in a method of an object reading its own private variables. Some do work, others don't. No scheme of finding out which will.

There may be a coincidence with the order of the vars in the VMT (looks as if the first one is the faulty one), but i cannot say so for sure.

I would really appreciate if this is fixed in 1.9.4.

Marc

Marc Santhoff
to Marco van de Voort: Don't expect it too soon, it is quite some work, and worse, the time between committing…
Show quoted text 19 lines
> > 1.9.4 reports: > > > > main192.pp(25,52) Error: Incompatible type for arg no. 1: Got "<address of > > procedure(TCustomer);CDecl>", expected "<procedure variable type of > > procedure(TCustomer);Register>" > > Ah, I see. I'll change the declaration of the callback proc then. > > I hope the version 1.9.4 is getting into the ports system of FreeBSD > soon, I got the port yesterday which is (not that far > behind ;). Don't expect it too soon, it is quite some work, and worse, the time between committing and submitting is quite long on avg. > Maybe I can use the Linux emulation and use 1.9.4/Linux for error > detection immediately ... Or simply use the 1.9.4/freebsd release?

I've got to look for it, if it's a package this would be okay, but using the installer made me search for files and tweaking paths and the like for days, I can't afford something like that right now.

Thanks for pointing out,
Marc

Marco van de Voort
to Marc Santhoff: oncemore for the sake of completeness: The 1.9.2 version of fpc is buggy on FreeBSD. I…
Show quoted text 7 lines
oncemore for the sake of completeness: The 1.9.2 version of fpc is buggy on FreeBSD. I get various problems in a method of an object reading its own private variables. Some do work, others don't. No scheme of finding out which will.

Then it is probably a memory problem. I used 1.9.2 and 1.9.3 a lot, and never noticed anything.

There may be a coincidence with the order of the vars in the VMT (looks as if the first one is the faulty one), but i cannot say so for sure. I would really appreciate if this is fixed in 1.9.4.

It will be hard without code to reproduce it.

Marc Santhoff
to Marco van de Voort
Show quoted text 10 lines
> oncemore for the sake of completeness: > > The 1.9.2 version of fpc is buggy on FreeBSD. > > I get various problems in a method of an object reading its own private > variables. Some do work, others don't. No scheme of finding out which > will. Then it is probably a memory problem. I used 1.9.2 and 1.9.3 a lot, and never noticed anything.

You're probably right with that. Debugging with stack checking impresses me very much ... <blush>

So i looked in the docs and asked myself:

What are the limits for stack and heap?
And why does the -Cs switch do nothing on Linux and FreeBSD?

Fact is, the stack is overflowing right at the start and i did not notice.

Marc

Peter Vreman
to Marc Santhoff
Show quoted text 7 lines
So i looked in the docs and asked myself: What are the limits for stack and heap? And why does the -Cs switch do nothing on Linux and FreeBSD? Fact is, the stack is overflowing right at the start and i did not notice.

That is part of Linux and FreeBSD in the docs is obsolete. Stackchecking is now platform independent.

Marc Santhoff
to Peter Vreman
Show quoted text 10 lines
> So i looked in the docs and asked myself: > > What are the limits for stack and heap? > And why does the -Cs switch do nothing on Linux and FreeBSD? > > Fact is, the stack is overflowing right at the start and i did not > notice. That is part of Linux and FreeBSD in the docs is obsolete. Stackchecking is now platform independent.

I think the stack can nearly never overflow having a limit (yes, I read the system docs ;) of 65536 kb for ordinary users on FreeBSD. Or is there any kind of segmentation an limits thereof in the game?

An should one trust the {$S+} switch? I get several overflow stops if it is activated in my units one by one but there seem to be no real fault ...

But I followed your (and Marco's) advice to use the newest version fpc 1.9.4 (that installed and works fine without path problems) and with the fixed debugging symbols I was able to hunt and shoot down my other bugs (not detected by 1.0.10).

The only thing I could not find out is what exactly went wrong with the 1.0.10. Now I cannot name the main problem ... but it has gone away and I'm happy.

Many thanks to you both for help and patience.

Marc