Re: [fpc-pascal] fp libraries do not like cmem ?
Hello Jeff. I will study your code. Many thanks. Fred ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fp libraries do not like cmem ?
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 0x00426ae6 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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fp libraries do not like cmem ?
On 14 Feb 2014, at 20:06, Fred van Stappen wrote: 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. 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. -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fp libraries do not like cmem ?
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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fp libraries do not like cmem ?
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? Ewald Yeep, 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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fp libraries do not like cmem ?
On 14 Feb 2014, at 20:28, Fred van Stappen wrote: 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... 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 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 ? 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. -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fp libraries do not like cmem ?
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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fp libraries do not like cmem ?
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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fp libraries do not like cmem ?
Am 13.02.2014 13:15, schrieb Fred van Stappen: 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). Please provide a simple, self contained example that shows this problem. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fp libraries do not like cmem ?
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)]
0x7fffefe08944 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.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fp libraries do not like cmem ?
Am 13.02.2014 17:04, schrieb Fred van Stappen:
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)]
0x7fffefe08944 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
-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
(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 ??
compiler, not debugger
ctypes, uos;
Put cmem at the first location of the library's uses clause (before the
ifdef).
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fp libraries do not like cmem ?
On Thu, February 13, 2014 17:13, Sven Barth wrote:
Am 13.02.2014 17:04, schrieb Fred van Stappen:
.
.
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)]
0x7fffefe08944 in ?? ()
from /home/fred/uoslib/examples/lib/Linux/64bit/libuos-64.so
.
.
Here the uses section :
uses
{$IFDEF UNIX}
cthreads,
cwstring, {$ENDIF}
cmem, // = debugger focus here, saying Error: Duplicate
identifier cmem ??
compiler, not debugger
ctypes, uos;
Put cmem at the first location of the library's uses clause (before the
ifdef).
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
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fp libraries do not like cmem ?
@ 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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fp libraries do not like cmem ?
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)] 0x7fffefe02c14 in ?? () from /home/fred/uoslib/examples/lib/Linux/64bit/libuos-64.so (gdb) bt #0 0x7fffefe02c14 in ?? () from /home/fred/uoslib/examples/lib/Linux/64bit/libuos-64.so #1 0x0040 in ?? () #2 0x7fffefe02d0e in ?? () from /home/fred/uoslib/examples/lib/Linux/64bit/libuos-64.so #3 0x7fffede0e088 in ?? () #4 0x7fffefdffdb0 in ?? () from /home/fred/uoslib/examples/lib/Linux/64bit/libuos-64.so #5 0x00de8f38 in ?? () #6 0x77e01240 in ?? () #7 0x00de8f30 in ?? () #8 0x7fffefe02e03 in ?? () from /home/fred/uoslib/examples/lib/Linux/64bit/libuos-64.so #9 0x7fffef5b8190 in ?? () #10 0x7fffefdffdb0 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... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fp libraries do not like cmem ?
On 13 Feb 2014, at 22:25, 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. -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fp libraries do not like cmem ?
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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fp libraries do not like cmem ?
bt full ? (gdb) bt full #0 0x7fffefe02c14 in ?? () from /home/fred/uoslib/src/libuoslib.so No symbol table info available. #1 0x0040 in ?? () No symbol table info available. #2 0x7fffefe02d0e in ?? () from /home/fred/uoslib/src/libuoslib.so No symbol table info available. #3 0x7fffede0e088 in ?? () No symbol table info available. #4 0x7fffefdffdb0 in ?? () from /home/fred/uoslib/src/libuoslib.so No symbol table info available. #5 0x00df6598 in ?? () Hum, not much more helpful... ;-( ps: The library was compiled with debug info too... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fp libraries do not like cmem ?
On Thu, February 13, 2014 22:25, Fred van Stappen wrote: Hi, . . 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)] 0x7fffefe02c14 in ?? () from /home/fred/uoslib/examples/lib/Linux/64bit/libuos-64.so (gdb) bt #0 0x7fffefe02c14 in ?? () from /home/fred/uoslib/examples/lib/Linux/64bit/libuos-64.so #1 0x0040 in ?? () #2 0x7fffefe02d0e in ?? () from /home/fred/uoslib/examples/lib/Linux/64bit/libuos-64.so #3 0x7fffede0e088 in ?? () #4 0x7fffefdffdb0 in ?? () from /home/fred/uoslib/examples/lib/Linux/64bit/libuos-64.so #5 0x00de8f38 in ?? () #6 0x77e01240 in ?? () #7 0x00de8f30 in ?? () #8 0x7fffefe02e03 in ?? () from /home/fred/uoslib/examples/lib/Linux/64bit/libuos-64.so #9 0x7fffef5b8190 in ?? () #10 0x7fffefdffdb0 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... 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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
