On 02/12/2014 08:55 PM, Fred van Stappen wrote:
you need synchronized heaps between the library and the
main program.
Exactly, that is what i want...
Unifying the heap is known to be necessary to successfully pass string
parameters between the main program and the library. Supposedly also
The bad news :
All programs using LCL (Lazarus widgetset) crash after thread.terminate
inside the library...
I dont know why, it is the same code and the same library.
Maybe i have to do something but i dont know what.
Using directly the uos unit, without using the library, is ok for LCL.
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
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
Hi All,
I encountered a very strange problem. The code looks like this:
//In Unit1.pas:
//sel is an object of TIntVector and
//TIntVector = specialize TVectorInteger
*sel.Sort([soEliminateNA, soReversed]); *
//In vector.pas:
procedure TVector.Sort(Options: SortOptions);
var
i, gap, order,
Am 13.02.2014 16:42, schrieb Xiangrong Fang:
Hi All,
I encountered a very strange problem. The code looks like this:
//In Unit1.pas:
//sel is an object of TIntVector and
//TIntVector = specialize TVectorInteger
*sel.Sort([soEliminateNA, soReversed]);
*
//In vector.pas:
procedure
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
Hi Sven,
I don't know how to find that, could you please explain? Attached
dbg.tar.bz2 is the demo program and assembly code generated by the compile.
Where is the point of specialization in that file?
My working program is quite complex, I copied part of the code related to
this problem in
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
On 13/02/2014 15:42, Xiangrong Fang wrote:
Hi All,
I encountered a very strange problem. The code looks like this:
//In Unit1.pas:
//sel is an object of TIntVector and
//TIntVector = specialize TVectorInteger
*sel.Sort([soEliminateNA, soReversed]);
*
//In vector.pas:
procedure
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
2014-02-14 0:16 GMT+08:00 Martin Frb laza...@mfriebe.de:
Is it just the debugger does not stop? But the statement is executed
(stopping in the next line never happens with FCount = 2)?
Check your setup
http://wiki.lazarus.freepascal.org/Debugger_Setup
- NO smartlinking
- NO optimization
2014-02-13 5:43 GMT-02:00 Sven Barth pascaldra...@googlemail.com:
Am 13.02.2014 01:28, schrieb silvioprog:
Hello,
Can I use it:
TBrookActionTBrookEntity = class(TBrookObject)
...
instead of?:
generic TBrookActionTBrookEntity = class(TBrookObject)
...
And, can I use it:
Hi Sven,
Sorry that I overlooked the problem. It is indeed a debugger problem. It
just stopped on the next line, but if I continue it just quit the function
nicely.
So, now the minor problem is, I don't have the blue dots :)
Sincerely,
Xiangrong
___
blue dots comes back after I switch back to O1...
Sorry for the false alarm... but this seems a debugger problem in lazarus
anyway...
2014-02-14 0:34 GMT+08:00 Xiangrong Fang xrf...@gmail.com:
Hi Sven,
Sorry that I overlooked the problem. It is indeed a debugger problem. It
just stopped
On 13/02/2014 16:36, Xiangrong Fang wrote:
blue dots comes back after I switch back to O1...
Sorry for the false alarm... but this seems a debugger problem in
lazarus anyway...
With -O2 and above the debugger does not always work.
In case of such optimization the debug info compiled into
@ 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,
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
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
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
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.
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
Hi Martin,
2014-02-14 1:14 GMT+08:00 Martin Frb laza...@mfriebe.de:
With -O2 and above the debugger does not always work.
In case of such optimization the debug info compiled into the exe by fpc
is not always accurate.
It is not just blue dots, inspecting variables may show random data,
On 14/02/2014 01:36, Xiangrong Fang wrote:
Hi Martin,
2014-02-14 1:14 GMT+08:00 Martin Frb laza...@mfriebe.de
mailto:laza...@mfriebe.de:
With -O2 and above the debugger does not always work.
In case of such optimization the debug info compiled into the exe
by fpc is not always
On 14.02.2014 03:11, Martin Frb wrote:
Strange though, because without blue dots, normally breakpoints to not
work, but yours did (on the wrong line, but it did break).
The only other thing I can think of is, if you have symlinks to your
files, and did open them in the IDE via different
25 matches
Mail list logo
