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
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: Poi
>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
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 cm
>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
>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
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
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
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 0x7f
>> 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
> 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 detai
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
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 u
@ 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, p
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
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 wo
> 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
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 lib
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
19 matches
Mail list logo
