|
|
How to reproduce? What OS and widgetset? |
|
|
I tested on linux. error in gtk2 and qt5 works fine when i revert revision 64110. |
|
|
I cannot reproduce. No sigabrt, no hang. I tested on Linux 64-bit using latest Lazarus trunk with QT5, GTK2 and GTK3 widgetsets. Please create a debugger backtrace. BTW, your main source Controller.lpr has Application.Terminate; at the end. It looks useless as the application is about to terminate anyways. Can somebody else reproduce? |
|
|
I did some tests here too. When I use FPC 3.2, this error doesn't happen. when I use the FPC trunk, I must revert revision 64110 to work. Maybe you can reproduce it on fpc trunk. Maybe is a FPC problem. |
|
|
What revision in FPC trunk caused it? The related Lazarus issue was inspired by FPC r47311. |
|
|
The Test app is flawed... That is an error in itself... Application.Run when exiting already has terminated what it needs, calling terminate again only generates useless bad code.. Terminate Is only suppose to be called during user code which then generates the series of events needed to terminate the Application.RUN loop. |
|
|
@jamie when you remove application.terminate the error is the same. @JuhaManninen 0038039 has been reopened, i'll folow it. Please, close this report as a duplicate. |
|
|
update all (fpc and Lazarus) to test it, and remove application.terminate FPC revision 48165 Lazarus revision 64401 Error is the same. and console returns "free(): invalid pointer" r64110.png (30,437 bytes) |
|
|
I will revert r64110 soon unless somebody comes up with a better idea. Does it have side effects? |
|
|
Do you get the same issue, if you move "uses cmem" to the top? Before "cthreads"? Do you get it, if you switch of heaptrc? |
|
|
Here is what valgrind says about your example app. And this goes away, if CMEM is used to the very top. Afaik memory manager units must be the very first item (or even given by special command line argument). May need to be double checked with an fpc, but afaik the uses order is wrong. If so, then this may be a user error, rather than a bug. Unless it can be reproduced with cmem on top (I could not reproduce it then) Also: mixing cmem and heaptrc (though it seems to work in many cases) may not be a good idea. At least fpc trunk will give an error when compiling with -gh -gv // -gv for valgrind does add cmem Error: You can not use both options (-gh) (-gv) at same time. Of course it does not say, if this error is because gv uses cmem, or due to any other issue. The error may mean that fpc trunk is more sensitive to any "unconventional" memmgr use.... ==86667== Invalid free() / delete / delete[] / realloc() ==86667== at 0x483CA3F: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==86667== by 0x45554F: CMEM_$$_CFREEMEM$POINTER$$QWORD (cmem.pp:75) ==86667== by 0x43CE26: fpc_freemem (heap.inc:369) ==86667== by 0x43C34A: SYSTEM_$$_DOEXITPROC (system.inc:1492) ==86667== by 0x43B8E2: SYSTEM_$$_INTERNALEXIT (system.inc:1188) ==86667== by 0x43BA98: fpc_do_exit (system.inc:1258) ==86667== by 0x41F190: main (Controller.lpr:22) ==86667== Address 0x484a0f8 is in a rw- anonymous segment ==86667== ==86667== Invalid free() / delete / delete[] / realloc() ==86667== at 0x483CA3F: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==86667== by 0x45554F: CMEM_$$_CFREEMEM$POINTER$$QWORD (cmem.pp:75) ==86667== by 0x43CE26: fpc_freemem (heap.inc:369) ==86667== by 0x43F80F: SYSTEM_$$_FINALIZELAZYINITTHREADING (thread.inc:372) ==86667== by 0x43C34D: SYSTEM_$$_DOEXITPROC (system.inc:1493) ==86667== by 0x43B8E2: SYSTEM_$$_INTERNALEXIT (system.inc:1188) ==86667== by 0x43BA98: fpc_do_exit (system.inc:1258) ==86667== by 0x41F190: main (Controller.lpr:22) ==86667== Address 0x48520f8 is in a rw- anonymous segment ==86667== Heap dump by heaptrc unit of "./Controller" 8 memory blocks allocated : 1492/1512 6 memory blocks freed : 1452/1472 2 unfreed memory blocks : 40 True heap size : 393216 True free heap : 392736 Should be : 392792 Call trace for block $0000000004852100 size 16 $000000000043CE07 fpc_getmem, line 364 of ../inc/heap.inc $000000000043F873 REGISTERLAZYINITTHREADINGPROC, line 390 of ../inc/thread.inc $0000000000481AB0 UNIX_$$_init$, line 1462 of ../unix/unix.pp $000000000043B627 fpc_initializeunits, line 1093 of ../inc/system.inc $000000000041F0D9 main, line 16 of Controller.lpr $000000000044A6A9 SYSENTRY, line 323 of system.pp Call trace for block $000000000484A100 size 24 $000000000043CE07 fpc_getmem, line 364 of ../inc/heap.inc $000000000043C377 ADDEXITPROC, line 1501 of ../inc/system.inc $000000000043F869 REGISTERLAZYINITTHREADINGPROC, line 389 of ../inc/thread.inc $0000000000481AB0 UNIX_$$_init$, line 1462 of ../unix/unix.pp $000000000043B627 fpc_initializeunits, line 1093 of ../inc/system.inc $000000000041F0D9 main, line 16 of Controller.lpr $000000000044A6A9 SYSENTRY, line 323 of system.pp |
|
|
@Martin You are right! it's a user error. The documentation explicitly says "it must be the first unit in uses clause": @JuhaManninen Don't revert it. close this topics and 0038039 too. Thanks! |
- Anonymous
