Hello.

This to note that a fp library does crash the program who call it, if that program uses cmem.

To reproduce the crash, create a fp library with a thread. Start the thread via the main program (who uses cmem) and it will crash when the library reach thread.terminate.

If you use cmem for the library himself, same behaviour, even if the main program do not use (or use cmem).

Thanks.

Fred

Please provide a simple, self contained example that shows this problem.

Regards,
Sven

Please provide a simple, self contained example that shows this

problem.

Regards, Sven

Hello.

Hum, i have done a simple library, with a thread and a simple program calling this library.

Not usefully to show it because, both using cmem are working perfectly... ;-)

So the problem is somewhere else.

I resume: if i use cmem in uses section of uos library (without debug on) it compile but i get that error when a program call the library (at thread.terminate):

Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffe859c700 (LWP 3289)]
0x00007fffefe08944 in ?? ()
from /home/fred/uoslib/examples/lib/Linux/64bit/libuos-64.so

I have then try to compile uos library with that parameters with debug : -MObjFPC -Scghi -O1 -gw2 -godwarfsets -gl -gv -Xg -gt -pg -vewnhi

and with cmem in uses section.

And now, fpc refuse to compile, focusing at cmem in uses section !

> simpleplayer.lpr(7,8) Error: Duplicate identifier "cmem"

I do not understand, i never declare cmem somewhere else, why does the debugger say me that ? (and sure, that is the problem=>solution).

Here the uses section :
uses
{$IFDEF UNIX}
cthreads,
cwstring, {$ENDIF}
cmem, // => debugger focus here, saying "Error: Duplicate identifier "cmem" ??

  ctypes, uos;

Many thanks.

Fred.

-gv which enables valgrind profiling needs cmem, so the compiler will include cmem and you did include cmem. Maybe this should be checked somehow... I suggest you not to use -gv and -pg except for profiling of performance or other things where you might need profiling.

I do not understand, i never declare cmem somewhere else, why does the debugger say me that ?

compiler, not debugger

compiler, not debugger

ctypes, uos;

Put cmem at the first location of the library's uses clause (before the ifdef).

Regards,
Sven

Sven Barth wrote

Am 13.02.2014 17:04, schrieb Fred van Stappen:

.
.

.
.

In addition, if that doesn't help, start your application with GDB ('gdb yourprogram'), 'run' it from there. After you get the SIGSEGV, request the backtrace (GDB command 'bt') to see the sequence leading to this situation. Observing the parameters may help in understanding what goes wrong (e.g. pointers containing a nil value where not expected or other senseless values not expected for real pointers, string parameters showing garbage, etc.).

Tomas

@ Sven and Tomas : many, many thanks for answer.

Ok, i will fight with the code tonight to (try) to understand what is wrong.

Write you later...

PS : Without cmem, the library is working perfectly. Last night i listen to songs many hours, with lot of DSP applied, changing that DPS at runtime, playing perfectly 16 songs-threads together without any crash (that never append with other audio libraries that i have try).

But i want to know why uos do not like cmem. So i go back to fight this night.

Many thanks.

Hello.

Here news from the front.

The good news. All console and fpGUI programs using cmem are working with the fp uos library.

There is only problem with LCL widgetset + cmem.

Here the result of debug + bt of a LCL program using cmem (no problem without cmem) : it does not help me, i do not understand the numbers :

Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffe8596700 (LWP 2580)]
0x00007fffefe02c14 in ?? ()
from /home/fred/uoslib/examples/lib/Linux/64bit/libuos-64.so

> (gdb) bt

#0 0x00007fffefe02c14 in ?? ()
from /home/fred/uoslib/examples/lib/Linux/64bit/libuos-64.so #1 0x0000000000000040 in ?? ()
#2 0x00007fffefe02d0e in ?? ()
from /home/fred/uoslib/examples/lib/Linux/64bit/libuos-64.so #3 0x00007fffede0e088 in ?? ()
#4 0x00007fffefdffdb0 in ?? ()
from /home/fred/uoslib/examples/lib/Linux/64bit/libuos-64.so #5 0x0000000000de8f38 in ?? ()
#6 0x00007ffff7e01240 in ?? ()
#7 0x0000000000de8f30 in ?? ()
#8 0x00007fffefe02e03 in ?? ()
from /home/fred/uoslib/examples/lib/Linux/64bit/libuos-64.so #9 0x00007fffef5b8190 in ?? ()
#10 0x00007fffefdffdb0 in ?? ()
from /home/fred/uoslib/examples/lib/Linux/64bit/libuos-64.so

@ Tomas, in earlier topic, you give result of gdb with much more details, how did you do it ? (i used bt, like you explained, but see the result, it is with much less details than yours...

Many thanks...

Fred van Stappen wrote

@ Tomas, in earlier topic, you give result of gdb with much more details, how did you do it ? (i used bt, like you explained, but see the result, it is with much less details than yours...

bt full ?

But if you don't have debug info for your library this won't help you much.

bt full ?

Yep, thanks Ewald, i will try that. ;-)

But if you don't have debug info for your library this won't help you much.

Hum, the library is fp, so i can compile with debug option. But maybe i do not use the good compiler-parameters.

What compiler-parameters will give me the most detailed debug infos ?

Many thanks.

> bt full ?

(gdb) bt full

#0 0x00007fffefe02c14 in ?? () from /home/fred/uoslib/src/libuoslib.so No symbol table info available.
#1 0x0000000000000040 in ?? ()
No symbol table info available.
#2 0x00007fffefe02d0e in ?? () from /home/fred/uoslib/src/libuoslib.so No symbol table info available.
#3 0x00007fffede0e088 in ?? ()
No symbol table info available.
#4 0x00007fffefdffdb0 in ?? () from /home/fred/uoslib/src/libuoslib.so No symbol table info available.
#5 0x0000000000df6598 in ?? ()

Hum, not much more helpful... ;-(

ps: The library was compiled with debug info too...

On Thu, February 13, 2014 22:25, Fred van Stappen wrote:

Hi,

.
.

You should compile both the library and your test program with -gw. Make sure to rebuild it fully (i.e. delete all *.ppu and *.o files before recompiling).

As mentioned by others somewhere else, it's better to turn optimizations off using -O- too in order to make sure that the debug information is accurate (this part may not be strictly necessary, but I'd do it anyway at least if the bt result isn't helpful enough).

Tomas

Hello.

It seams to me that i monopolize the forum here.
Please advice if it borrow you, i will stop directly... ;-)

I still fight with cmem and trust me, it is a hard battle. Mainly because the debugger gives me very few infos and because, if i do not use cmem, all examples are working perfectly, the debugger is happy and do not gives me any warning, only lot of "OK" ...

So difficult to understand why LCL+cmem do not like uos library.

I follow the advices of Tomas and the debugger gives me a (very) few more infos. One is that:

#8 0x0000000000426ae6 in fpc_ansistr_decr_ref ()

So i isolate the only function who gives as result string (and is working without cmem):

function uos_GetInfoDeviceStr() : String ;
var
myresult : string;
begin
...
result := myresult;
end;

I changed with

function uos_GetInfoDeviceStr() : PChar ;
var
myresult : string;
begin
...
result := @myresult;
end;

And that is ok, no more crash and debugger is happy...

But now, when i try to retrieve the result with, for example :

procedure getinfo ;
var
mystring : string;
begin
mystring := uos_GetInfoDeviceStr();
end;

I get:
=> mystring = '' (empty string).

How must i do to retreive the data of Pchar (the result of uos_GetInfoDeviceStr()) ?

PS : It seams that cmem prefers pointers as result, so, maybe i have to change all functions to give pointers as result (yes/no?).

Many thanks.

What I have been wondering for some time now (perhaps you wrote it in a mail and I missed it): do you use the same memory manager in the library and in your test program?

Also, beware when returning pointers. Consider this snippet:

Procedure ReturnTheAnwer: PInteger;
Var	a: Integer;
Begin
	a:= 42;
	Result:= @a;
End;

One might think at first glance that `ReturnTheAnswer^` is 42, but this is incorrect in some cases. The example here might be extremely over-simplified, but replace `a: Integer` with `mystring: String` and we're roughly at your example.

What I have been wondering for some time now (perhaps you wrote it in a mail and I missed it): do you use the same memory manager in the library and in your test program?

Oops, indeed i forget that point...
The test now are with cmem only in program, not in library.

I will test with cmem into library too...

The example here might be extremely over-simplified, but replace `a: Integer` with `mystring: String` and we're roughly at your example.

Hum, absolutely, it is the same example...
So, how must i do to use PChar ?

Many thanks.

That that is issue number 1: if your program wants to free something that your library allocated, both operations need to be done by the same memory manager.

The way I use to pass strings from C/C++ libraries is to allocate a buffer, copy the contents of the string into the buffer and return the pointer to that buffer. The same method can be used here. Also don't forget to provide a second function to free these buffers (in this way your library can have a different memory manager than your application).

So you might try something along the lines of:

Function ConvertToPChar(str: String): PChar;
Begin
	Result:= Getmem(Length(str) + 1);	// Allocating the buffer somewhere on the heap
	If Length(str) > 0 Then
		Move(str[1], Result[0], Length(str));	// The content
	Result[l]Length(str)]:= #0;	// The null termination
End;

..., where I decided to return `standard` null-terminated strings, since your library is meant to be `universal`.

Next, the procedure to free buffers using the memory manager of the library:

Procedure FreeBuffer(Buffer: Pointer);
Begin
	FreeMem(Buffer);
End;

That's it for the library part. In your program part, don't forget to free these buffers once they are no longer needed.

Also note that this is a good approach with respect to `universiality`, but if you need to pass a lot of strings to and fro you would be better off with a more pascalish version. The thing that comes to mind here is providing a function in your library that replaces the current memory manager with the one passed to it as an argument. This would allow you to simply return a string.

Yeeeeeep, Ewald, you are the Winner.
And you impress me a lot with your perspicacity.

The battle has ended, with big triumph of fpc.

That does the trick:
Use cmem in both library and program... it works... :-)

Conclusion: That long but exciting adventure prove that fpc is the future, fpc will unify all the other libraries, from all languages and all os and will be the Conductor of that great unification.

Long life to fpc.

Many thanks for your help, wonderful fpc people.

Fred

Also note that this is a good approach with respect to

`universiality`, but if you need to...

Ewald

Thanks Ewald for your useful advices.

Now, a other battle will begin :

Create headers for C, CNet, Basic, Java, ... and translate all the uos Pascal examples.

But that is not the problem of fpc...

So, i will borrow now the forum of all those language :-) !

Bye and, one more time : tetra thanks.

Fred.

Or always allocate and free the buffer in the calling program and load the contents into the buffer in the dll. This way you never have to worry about allocating in one place and freeing in the other. Windows API does stuff like this a lot.

In the DLL:

Procedure GetSomeString(StringPointer: Pointer, Var StringLen: Integer);
Begin
  StringLen = CalculateSizeOfString
  if StringPointer != nil then
    // copy string to StringPointer
End;

In your App:

Var StringLen: Integer;
AllocedMem : Pointer;
. . .
// Find out how much memory needed
GetSomeString(nil, &StringLen);
GetMem(AllocedMem, StringLen);
GetSomeString(AllocedMem, &StringLen);
// use the string for whatever you need
. . .
FreeMem(AllocedMem);

Very bad psuedo code there, but it should give you the idea.

To summarize, your app needs to:

1. Call once with nil to get how much memory needed
2. Allocate the memory
3. Call again with pointer to memory
4. Use the allocated memory
5. Free the allocated memory

And your dll function needs to:

1. Check pointer for nil
2. If so, only set the length parameter to the size of memory needed and exit
3. If not, copy data to pointer as well

Jeff.

Hello Jeff.

I will study your code.

Many thanks.

Fred