I'm creating a very basic TCustomControl with just a Constructor and its Destructor.

TMyCustomControl = class(TCustomControl)
public
  constructor Create(TheOwner: TComponent);override;
  destructor Destroy; override;
end;

In a main form's TForm.Create I'm creating an instance of my TCustomControl, which is declared as a form variable, like FMyCustomControl, for example:

constructor TMyForm.FormCreate(Sender: TObject);
begin
  FMyCustomControl := TMyCustomControl.Create(Self);
end;

So far TMyCustomControl's constructor is called, I can debug it, and it's working ok.

Now, from another method of MyForm, I need to call a method of TMyCustomControl, but I get a SIGSEGV:

procedure TMyForm.TestCustomControl;
begin
  FMyCustomControl.DoSomething;
end;

Apparently the reference of FMyCustomControl is lost.

I'm missing something?. Should I set or inherit more methods of TCustomControl to make it work?.

Regards,

What are the contents of your constructor?

-Fl?vio

constructor TMyCustomControl.Create(TheOwner: TComponent);
begin
  inherited Create(TheOwner);
end;

And what are the contets of DoSomething method?

Marcos Douglas

procedure TMyCustomControl.DoSomething;
begin
  ShowMessage('hello');
end;

As you can see, this is a very basic control I'm just trying to create.

Can you provide the full unit, or better a trimmed down one?

Stephano

Let me do some checks before, my program was loading a shared library which aparently is causing this behavior.

I'm using a C++ library with a function that receives a parameter this way:

int getData(void * &buffer, unsigned long &bufSize){
  bufSize = 10;
  return 1;
}

The Pascal definition I'm using is this:

function (var buffer: pointer; var bufsize: longword): Integer; cdecl;

I'm using this library without any issue in a couple of programs, but in this new program, after the "bufSize" variable is assigned (inside the library) an object of my Lazarus program is trashed. Weird.

The instance of my object (an very simple TCustomControl descendant) is declared in a TForm class, as FMyControl: TMyControl, then created an instance in TForm's constructor. In another method of TForm, I call the library's function then I try to use a method of FMyControl, but it gives a SigSegv.

Example:

procedure TForm1.doSomething;
var
  lBuffer: PWord;
  lBufSize: longword;
begin
  lBuffer := nil;
  lBufSize := 0;
  FMyControl.call_some_method; // FMyControl has debugging info.
  getData(lBuffer, lBufSize);
  FMyControl.call_some_method; // FMyControl "cannot access memory address...SIGSEGV"
end;

I can modify the C++ function if needed. Am I incorrectly declaring the function params?. Why is FMyControl's memory position trashed?.

Regards,

I think you could not declare the second parameter of GetData as var parameter. Because it is then treated as address.
I am not sure what corresponds to C++ unsigned long, perhaps LongWord? So try to change the second parameter so that it is not a var parameter. D?a 19. 4. 2013 19:18 Leonardo M. Ram? wrote / nap?sal(a):

But I need the 2nd param to be changed by the function, that's why I declare it as var.

I probably don't understand. You will be able to change it, I see no problem. It is a local variable which can be changed.

D?a 19. 4. 2013 20:55 Leonardo M. Ram? wrote / nap?sal(a):

Well, removing the "var" in the 2nd param, at least allowed avoid the SIGSEGV. I don't know why, though.

This is How I understand the var parameter.
It is an address, but is treated as normal variable, so it is not needed to dereference a pointer.
For example
int f(int* x) in C/C++ corresponds to
function f(var x: integer): integer;
Now we have
int f(int x);
If you declare it as
function f(var x: integer): integer;
and then try to assign something to x, the access violation is very probably raised because x contains value, not address. D?a 19. 4. 2013 21:15 Leonardo M. Ram? wrote / nap?sal(a):

On 2013-04-19 21:08:29 +0200, Lubos Pintes wrote: > I probably don't understand. You will be able to change it, I see no > problem. It is a local variable which can be changed.

You're right, C++ "&" is equivalent to Pascal "var".

Well, removing the "var" in the 2nd param, at least allowed avoid the SIGSEGV. I don't know why, though.

I suspect a wrong calling convention.

DoDi

Thanks for the explanation Lubos, much clear now.

Yet another thing, someone also mentioned this.
The cdecl calling convention corresponds to extern "C" in C++. Maybe you are using stdcall in your C++ library?
Or perhaps you are on Linux where this is not relevant? But the extern "C" could be relevant also on Linux.

D?a 19. 4. 2013 21:24 Lubos Pintes wrote / nap?sal(a):