Re: [fpc-pascal] weird compiler(?) problem

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 links/or

Re: [fpc-pascal] weird compiler(?) problem

On 14/02/2014 01:36, Xiangrong Fang wrote: Hi Martin, 2014-02-14 1:14 GMT+08:00 Martin Frb >: 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 i

Re: [fpc-pascal] weird compiler(?) problem

Hi Martin, 2014-02-14 1:14 GMT+08:00 Martin Frb : > 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, > > Debug

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 0x7f

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

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 detai

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

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 u

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, p

Re: [fpc-pascal] weird compiler(?) problem

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 t

Re: [fpc-pascal] weird compiler(?) problem

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 : > Hi Sven, > > Sorry that I overlooked the problem. It is indeed a debugger problem. It > just stopped on the next li

Re: [fpc-pascal] weird compiler(?) problem

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 ___ f

Re: [fpc-pascal] Generics and key words

2014-02-13 5:43 GMT-02:00 Sven Barth : > Am 13.02.2014 01:28, schrieb silvioprog: > >> Hello, >> >> Can I use it: >> >> TBrookAction = class(TBrookObject) >> ... >> >> instead of?: >> >> generic TBrookAction = class(TBrookObject) >> ... >> >> And, can I use it: >> >> TPersonAction = class(TBrookAc

Re: [fpc-pascal] weird compiler(?) problem

2014-02-14 0:16 GMT+08:00 Martin Frb : > > 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 > -O1 is

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

Re: [fpc-pascal] weird compiler(?) problem

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 TVector *sel.Sort([soEliminateNA, soReversed]); * //In vector.pas: procedure TVector.Sort(Options

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 wo

Re: [fpc-pascal] weird compiler(?) problem

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 sn

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

Re: [fpc-pascal] weird compiler(?) problem

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 TVector *sel.Sort([soEliminateNA, soReversed]); * //In vector.pas: procedure TVector.Sort(Option

[fpc-pascal] weird compiler(?) problem

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 TVector *sel.Sort([soEliminateNA, soReversed]); * //In vector.pas: procedure TVector.Sort(Options: SortOptions); var i, gap, order, first,

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 lib

[fpc-pascal] fp libraries do not like cmem ?

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

Re: [fpc-pascal] fp universal library ?

>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 L

Re: [fpc-pascal] Can a library synchronize foreign procedure ?

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 als