Main place for discussions about U++ cross platform development framework.
https://sourceforge.net/projects/upp/upload/upp/2025.1rc4/
Crash with TheIDE on macOS 10.15.7 (Intel). Latest src. $ /Users/xxx/dvlp/cpp/code/upp/out/CLANG.Blitz.Gui.Shared/ide.app/Contents/MacOS/ide 2025-03-12 23:29:48.923 ide[42704:1183943] -[NSCompositeAppearance performAsCurrentDrawingAppearance:]: unrecognized selector sent to instance 0x7fd8a2414fb0 2025-03-12 23:29:48.924 ide[42704:1183943] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[NSCompositeAppearance performAsCurrentDrawingAppearance:]: unrecognized selector sent to instance 0x7fd8a2414fb0' *** First throw call stack: ( 0 CoreFoundation 0x00007fff2e9b9a17 __exceptionPreprocess + 250 1 libobjc.A.dylib 0x00007fff674d7a9e objc_exception_throw + 48 2 CoreFoundation 0x00007fff2ea38e36 -[NSObject(NSObject) __retain_OA] + 0 3 CoreFoundation 0x00007fff2e91e190 _forwarding_ + 1427 4 CoreFoundation 0x00007fff2e91db68 _CF_forwarding_prep_0 + 120 5 ide 0x00000001004eeb6a _Z12Coco_PaintChPviii + 106 6 ide 0x00000001004cad94 _ZN3Upp7CocoImgENS_5ColorEiii + 148 7 ide 0x00000001004c8e87 _ZN3Upp10ChHostSkinEv + 135 8 ide 0x00000001008827ef _ZN3Upp4Ctrl6ReSkinEv + 159 9 ide 0x00000001008bd4f7 _ZN3Upp8CocoInitEiPPKcS2_ + 519 10 ide 0x0000000100228cbe main + 270 11 libdyld.dylib 0x00007fff68677cc9 start + 1 ) libc++abi.dylib: terminating with uncaught exception of type NSException
Novo wrote on Thu, 13 March 2025 04:42 Crash with TheIDE on macOS 10.15.7 (Intel). Latest src. $ /Users/xxx/dvlp/cpp/code/upp/out/CLANG.Blitz.Gui.Shared/ide.app/Contents/MacOS/ide 2025-03-12 23:29:48.923 ide[42704:1183943] -[NSCompositeAppearance performAsCurrentDrawingAppearance:]: unrecognized selector sent to instance 0x7fd8a2414fb0 2025-03-12 23:29:48.924 ide[42704:1183943] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[NSCompositeAppearance performAsCurrentDrawingAppearance:]: unrecognized selector sent to instance 0x7fd8a2414fb0' *** First throw call stack: ( 0 CoreFoundation 0x00007fff2e9b9a17 __exceptionPreprocess + 250 1 libobjc.A.dylib 0x00007fff674d7a9e objc_exception_throw + 48 2 CoreFoundation 0x00007fff2ea38e36 -[NSObject(NSObject) __retain_OA] + 0 3 CoreFoundation 0x00007fff2e91e190 _forwarding_ + 1427 4 CoreFoundation 0x00007fff2e91db68 _CF_forwarding_prep_0 + 120 5 ide 0x00000001004eeb6a _Z12Coco_PaintChPviii + 106 6 ide 0x00000001004cad94 _ZN3Upp7CocoImgENS_5ColorEiii + 148 7 ide 0x00000001004c8e87 _ZN3Upp10ChHostSkinEv + 135 8 ide 0x00000001008827ef _ZN3Upp4Ctrl6ReSkinEv + 159 9 ide 0x00000001008bd4f7 _ZN3Upp8CocoInitEiPPKcS2_ + 519 10 ide 0x0000000100228cbe main + 270 11 libdyld.dylib 0x00007fff68677cc9 start + 1 ) libc++abi.dylib: terminating with uncaught exception of type NSException Works on M2 mac with Sonoma.. But I guess as this has something to do with selector in Coco_ChPaint, I have tried this fix: https://github.com/ultimatepp/ultimatepp/commit/6cebecec4d7b 0962668c5c90f04ed1a8229787dd Please let me know. If this does not help, it would be worth trying to revert the whole function pre 12/2024 state just to check the reason.
I'm sorry to say that but your fix didn't help. Latest src. (lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT * frame #0: 0x00007fff687bf32a libsystem_kernel.dylib`__pthread_kill + 10 frame #1: 0x00007fff6887fe60 libsystem_pthread.dylib`pthread_kill + 430 frame #2: 0x00007fff68746808 libsystem_c.dylib`abort + 120 frame #3: 0x00007fff659ab458 libc++abi.dylib`abort_message + 231 frame #4: 0x00007fff6599c8bf libc++abi.dylib`demangling_terminate_handler() + 262 frame #5: 0x00007fff674d9a57 libobjc.A.dylib`_objc_terminate() + 96 frame #6: 0x00007fff659aa887 libc++abi.dylib`std::__terminate(void (*)()) + 8 frame #7: 0x00007fff659ad1a2 libc++abi.dylib`__cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception*) + 27 frame #8: 0x00007fff659ad169 libc++abi.dylib`__cxa_throw + 113 frame #9: 0x00007fff674d7bcc libobjc.A.dylib`objc_exception_throw + 350 frame #10: 0x00007fff2ea38e36 CoreFoundation`-[NSObject(NSObject) doesNotRecognizeSelector:] + 132 frame #11: 0x00007fff2e91e190 CoreFoundation`___forwarding___ + 1427 frame #12: 0x00007fff2e91db68 CoreFoundation`__forwarding_prep_0___ + 120 frame #13: 0x00000001004963fe ide`Coco_PaintCh(cgcontext=0x0000000102b13a10, type=7, value=1, state=0) at ChCocoMM.mm:99:2 frame #14: 0x0000000100440367 ide`Upp::CocoImg(bg=(color = 1073741824), type=7, value=1, state=0) at ChCoco.cpp:47:2 frame #15: 0x00000001004407ea ide`Upp::CocoColor(k=1, bg=(color = 1073741824)) at ChCoco.cpp:69:18 frame #16: 0x000000010043e70e ide`Upp::ChHostSkin() at ChCoco.cpp:136:20 frame #17: 0x0000000100a2979f ide`Upp::Ctrl::ReSkin() at Ctrl.cpp:951:3 frame #18: 0x0000000100a29dc0 ide`Upp::Ctrl::SetUHDEnabled(set=true) at Ctrl.cpp:794:2 frame #19: 0x0000000100a6eb05 ide`Upp::CocoInit(argc=1, argv=0x00007ffeefbff568, envptr=0x00007ffeefbff578) at CocoApp.mm:99:2 frame #20: 0x00000001000ee90c ide`main(argc=1, argv=0x00007ffeefbff568, envptr=0x00007ffeefbff578) at main.cpp:178:1 frame #21: 0x00007fff68677cc9 libdyld.dylib`start + 1 frame #22: 0x00007fff68677cc9 libdyld.dylib`start + 1 This is what I've found: AppKit macOS 10.15.6 to 11.0 API Differences [NSAppearance performAsCurrentDrawingAppearance:] was added in 11.0. It is not available in 10.15. It would be great to be able to detect version of API at run time (or at compile time) and adapt code accordingly ...
Novo wrote on Sat, 15 March 2025 05:11 I'm sorry to say that but your fix didn't help. Latest src. (lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT * frame #0: 0x00007fff687bf32a libsystem_kernel.dylib`__pthread_kill + 10 frame #1: 0x00007fff6887fe60 libsystem_pthread.dylib`pthread_kill + 430 frame #2: 0x00007fff68746808 libsystem_c.dylib`abort + 120 frame #3: 0x00007fff659ab458 libc++abi.dylib`abort_message + 231 frame #4: 0x00007fff6599c8bf libc++abi.dylib`demangling_terminate_handler() + 262 frame #5: 0x00007fff674d9a57 libobjc.A.dylib`_objc_terminate() + 96 frame #6: 0x00007fff659aa887 libc++abi.dylib`std::__terminate(void (*)()) + 8 frame #7: 0x00007fff659ad1a2 libc++abi.dylib`__cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception*) + 27 frame #8: 0x00007fff659ad169 libc++abi.dylib`__cxa_throw + 113 frame #9: 0x00007fff674d7bcc libobjc.A.dylib`objc_exception_throw + 350 frame #10: 0x00007fff2ea38e36 CoreFoundation`-[NSObject(NSObject) doesNotRecognizeSelector:] + 132 frame #11: 0x00007fff2e91e190 CoreFoundation`___forwarding___ + 1427 frame #12: 0x00007fff2e91db68 CoreFoundation`__forwarding_prep_0___ + 120 frame #13: 0x00000001004963fe ide`Coco_PaintCh(cgcontext=0x0000000102b13a10, type=7, value=1, state=0) at ChCocoMM.mm:99:2 frame #14: 0x0000000100440367 ide`Upp::CocoImg(bg=(color = 1073741824), type=7, value=1, state=0) at ChCoco.cpp:47:2 frame #15: 0x00000001004407ea ide`Upp::CocoColor(k=1, bg=(color = 1073741824)) at ChCoco.cpp:69:18 frame #16: 0x000000010043e70e ide`Upp::ChHostSkin() at ChCoco.cpp:136:20 frame #17: 0x0000000100a2979f ide`Upp::Ctrl::ReSkin() at Ctrl.cpp:951:3 frame #18: 0x0000000100a29dc0 ide`Upp::Ctrl::SetUHDEnabled(set=true) at Ctrl.cpp:794:2 frame #19: 0x0000000100a6eb05 ide`Upp::CocoInit(argc=1, argv=0x00007ffeefbff568, envptr=0x00007ffeefbff578) at CocoApp.mm:99:2 frame #20: 0x00000001000ee90c ide`main(argc=1, argv=0x00007ffeefbff568, envptr=0x00007ffeefbff578) at main.cpp:178:1 frame #21: 0x00007fff68677cc9 libdyld.dylib`start + 1 frame #22: 0x00007fff68677cc9 libdyld.dylib`start + 1 This is what I've found: AppKit macOS 10.15.6 to 11.0 API Differences [NSAppearance performAsCurrentDrawingAppearance:] was added in 11.0. It is not available in 10.15. It would be great to be able to detect version of API at run time (or at compile time) and adapt code accordingly ... Ah, stupid me, I missed that you are testing on old macos (10.15 vs 15.xx). This should help: https://github.com/ultimatepp/ultimatepp/commit/d58a5e54abf9 3f56da44e4b987a17f52a46b2ba9
Thanks. Exception is gone. Application menu is gone as well. It works, but it is invisible. MacOS 15.3.1 is fine. It works and menu is visible.
Another problem with MacOS is that TheIDE launches gdb on F5. It is supposed to be lldb ...
Novo wrote on Sat, 15 March 2025 16:20 Thanks. Exception is gone. Application menu is gone as well. It works, but it is invisible. MacOS 15.3.1 is fine. It works and menu is visible. Well, I have added "flicker prevention" for the main menu, I guess it might be the cause. Can you try with void CocoMenuBar::Set(Event<Bar&> bar) { if(lock) return; lock++; [cocomenu removeAllItems]; bar(*this); lock--; } (I do not see any obvious reason now why it should not work, but at least this might narrow it down).
mirek wrote on Sun, 16 March 2025 04:37 Well, I have added "flicker prevention" for the main menu, I guess it might be the cause. Can you try with void CocoMenuBar::Set(Event<Bar&> bar) { if(lock) return; lock++; [cocomenu removeAllItems]; bar(*this); lock--; } (I do not see any obvious reason now why it should not work, but at least this might narrow it down). With this implementation of CocoMenuBar::Set menu works fine.
Novo wrote on Sun, 16 March 2025 23:05 mirek wrote on Sun, 16 March 2025 04:37 Well, I have added "flicker prevention" for the main menu, I guess it might be the cause. Can you try with void CocoMenuBar::Set(Event<Bar&> bar) { if(lock) return; lock++; [cocomenu removeAllItems]; bar(*this); lock--; } (I do not see any obvious reason now why it should not work, but at least this might narrow it down). With this implementation of CocoMenuBar::Set menu works fine. But it flickers... So I guess we should make it work with current code. Anyway, after staring to the code for 40 minutes, I still cannot see the reason. So I have added some most likely possible fix, can you test please with master? If that does not help, I would welcome adding some LOGs/DUMPs in some places...
mirek wrote on Mon, 17 March 2025 04:11 But it flickers... So I guess we should make it work with current code. Anyway, after staring to the code for 40 minutes, I still cannot see the reason. So I have added some most likely possible fix, can you test please with master? If that does not help, I would welcome adding some LOGs/DUMPs in some places... Menu is gone again ... Where would you like to add LOGs/DUMPs?
Novo wrote on Mon, 17 March 2025 16:19 mirek wrote on Mon, 17 March 2025 04:11 But it flickers... So I guess we should make it work with current code. Anyway, after staring to the code for 40 minutes, I still cannot see the reason. So I have added some most likely possible fix, can you test please with master? If that does not help, I would welcome adding some LOGs/DUMPs in some places... Menu is gone again ... Where would you like to add LOGs/DUMPs? Wait a moment: Does it mean that what is missing is texts? I mean, that submenus are under "spaces"? Mirek
mirek wrote on Mon, 17 March 2025 15:18 Wait a moment: Does it mean that what is missing is texts? I mean, that submenus are under "spaces"? Mirek That is correct. As I wrote previously: "It works, but it is invisible.". Probably, I should've described the problem in more details.
OK, please try this CocoMenuBar::Item& CocoMenuBar::Item::Text(const char *text) { DLOG("===="); DDUMP(bar->just_check); String txt = text; if(bar->just_check) { if(txt != this->text) bar->is_same = false; DDUMP(bar->is_same); return *this; } this->text = txt; String h; DDUMP(text); while(*text) { if(*text == '&') { text++; if(*text == '&') { h.Cat('&'); text++; } } else h.Cat(*text++); } DDUMP(h); DDUMP(~submenu); NSString *s = [NSString stringWithUTF8String:~h]; nsitem.title = s; if(submenu) submenu->cocomenu.title = s; return *this; } Thank you!
mirek wrote on Mon, 17 March 2025 18:51 OK, please try this I checked this with macOS 10.15. It didn't help. Another weird thing: ide doesn't create a log file ... I ran a debug version ...
Another problem with TheIDE (detected on macOS 10.15 but it should be present on all platforms). Steps to reproduce: 1) Launch a debug version of TheIDE (because it is slower). 2) Open a tutorial/Gui01 project and close it immediately before clangd finishes its job. 3) Launch a debug version of TheIDE again. 4) Open the tutorial/Gui01 project again. 5) Observe hanging TheIDE. It looks like TheIDE stores intermediate data during clangd initialization. If you quit TheIDE before clangd finishes its job this data gets broken.
Novo wrote on Tue, 18 March 2025 04:52 Another problem with TheIDE (detected on macOS 10.15 but it should be present on all platforms). Steps to reproduce: 1) Launch a debug version of TheIDE (because it is slower). 2) Open a tutorial/Gui01 project and close it immediately before clangd finishes its job. 3) Launch a debug version of TheIDE again. 4) Open the tutorial/Gui01 project again. 5) Observe hanging TheIDE. It looks like TheIDE stores intermediate data during clangd initialization. If you quit TheIDE before clangd finishes its job this data gets broken. I do not observe any of these ill effects... .log not working is really strange and I guess it is where we should start for now. It is just using POSIX filesystem right? Does very simple app with single SaveFile(...) work? (Like does it save the data?) Can you test .log with something trivial like CONSOLE_APP_MAIN {} ? Also, quote likely culprit: The position of .log file in POSIX system has changed. Are you trying with latest ide? (so that theide knows where to look for it?) Maybe it gets generated, just Alt-L in theide does not know where to look for it? GetFileFolder(GetUserConfigDir()) + "/.local/state/" + GetConfigGroup() + "/log/" + GetAppName() ~/.local/state/u++/log/...
Hello, I would like to jump to the discussion. Do we want to support macOS 10.15, if it is currently not supported by Apple? The support for this OS ended on 12 Sep 2022, which is 2 and the half years ago. For me, we should focus only on macOS that is currently supported by the Apple. We don't have enough manpower for that. Also, Intel CPU's are supported on the latest version of macOS, which is macOS Sequoia (15.0). So, we will do not drop architecture, but only unsupported versions. BTW, There is a compilation issue on our pipelines. We should focus to fix this issue... Sources: - https://endoflife.date/macos Klugier
mirek wrote on Tue, 18 March 2025 06:21 ~/.local/state/u++/log/... This is how it looks in GUI ... It turned out that a log-file is created, but it is located in [root of .config]/.local/state/u++/log/... And TheIDE looks for a log file in a fixed place and ignores GetFileFolder(GetUserConfigDir()) ...
This is a log file with your version of CocoMenuBar::Item::Text ...
mirek wrote on Tue, 18 March 2025 06:21 I do not observe any of these ill effects... It is reproducible in my case. Sometimes I need to call TheIDE several times till it friezes.
Klugier wrote on Tue, 18 March 2025 14:26 Hello, I would like to jump to the discussion. Do we want to support macOS 10.15, if it is currently not supported by Apple? The support for this OS ended on 12 Sep 2022, which is 2 and the half years ago. For me, we should focus only on macOS that is currently supported by the Apple. We don't have enough manpower for that. Also, Intel CPU's are supported on the latest version of macOS, which is macOS Sequoia (15.0). So, we will do not drop architecture, but only unsupported versions. BTW, There is a compilation issue on our pipelines. We should focus to fix this issue... Sources: - https://endoflife.date/macos Klugier Well, a lot of people (including me) use old hardware. I even bought a server rack to put all my old servers into it Used professional hardware is very good and cheap I bought a brand new iMac for my wife. It broke in five years. I bought another brand new iMac. It broke in five years as well. After that I decided not to waste my money on Apple's hardware and bought an old iMac off ebay for a tiny fraction of price of a new one. I also bought a spare one because I didn't expect the first one to last for very long. Interestingly, the first one still works and it runs macOS 10.13 And I have an old MacBook Pro which runs macOS 10.15. I do not need anything better than this MacBook. It has 16GB of RAM and runs photo processing software I use Well, I also have a spare iMac which I bought for my wife So, support of the old hardware is important. I also thinking about using of U++ for IoT projects. These days C++ became new assembler
Klugier wrote on Tue, 18 March 2025 19:26 Hello, I would like to jump to the discussion. Do we want to support macOS 10.15, if it is currently not supported by Apple? The support for this OS ended on 12 Sep 2022, which is 2 and the half years ago. For me, we should focus only on macOS that is currently supported by the Apple. We don't have enough manpower for that. Also, Intel CPU's are supported on the latest version of macOS, which is macOS Sequoia (15.0). So, we will do not drop architecture, but only unsupported versions. BTW, There is a compilation issue on our pipelines. We should focus to fix this issue... Sources: - https://endoflife.date/macos Klugier It is true, however I think it is wise to pursue this, at least for the "hidden menu issue", as there is no obvious reason for it not to work and so it can be a hidden bug (that would strike back later in some corner case).
Novo wrote on Tue, 18 March 2025 22:24 mirek wrote on Tue, 18 March 2025 06:21 ~/.local/state/u++/log/... This is how it looks in GUI ... It turned out that a log-file is created, but it is located in [root of .config]/.local/state/u++/log/... And TheIDE looks for a log file in a fixed place and ignores GetFileFolder(GetUserConfigDir()) ... Well, it appears you might have active "sandboxing feature" (that is, you have .config in some dir that is parent of executable dir and is not ~/.config). Which is something that was not accounted for in TheIDE. Tried to fix it... https://github.com/ultimatepp/ultimatepp/commit/4c6c1d701c77 d3622c51767e39c2f7cf754a1cf6
Novo wrote on Mon, 17 March 2025 22:53 mirek wrote on Mon, 17 March 2025 15:18 Wait a moment: Does it mean that what is missing is texts? I mean, that submenus are under "spaces"? Mirek That is correct. As I wrote previously: "It works, but it is invisible.". Probably, I should've described the problem in more details. OK, .log ruled out some issues, so I have tried to fix something else: https://github.com/ultimatepp/ultimatepp/commit/2c64e6cb50a0 5dba0eae893c3985ee139a7fd25d Please check.
mirek wrote on Wed, 19 March 2025 05:59 Please check. Menu works. Viewing of log-files with TheIDE works. TheIDE doesn't seem to hang anymore. Thank you!
Novo wrote on Wed, 19 March 2025 18:39 mirek wrote on Wed, 19 March 2025 05:59 Please check. Menu works. Viewing of log-files with TheIDE works. TheIDE doesn't seem to hang anymore. Thank you! Thats a good news! Thanks for testing and patience.
I checked TheIDE with valgrind (debug version of TheIDE + open the ide package). A result is attached. I ran valgrind three times and each time result was different. This doesn't look good to me. I doubt that this is a problem with clangd itself.
Interestingly, I tried to compile TheIDE with a USEMALLOC flag and got a result below. Linking... /bin/x86_64-unknown-linux-gnu-ld: /home/xxx/dvlp/cpp/code/upp/out/Core/SSL/CLANGcpp17um.Debug.Debug_Full.Gui.Shared/Util.o: in function `__cxx_global_var_init': /home/xxx/dvlp/cpp/code/upp/git/uppsrc/Core/Core.h:426:(.text.startup+0xc): undefined reference to `MemDiagCls::MemDiagCls()' /bin/x86_64-unknown-linux-gnu-ld: /home/xxx/dvlp/cpp/code/upp/out/Core/SSL/CLANGcpp17um.Debug.Debug_Full.Gui.Shared/Util.o: in function `__cxx_global_var_init': /home/xxx/dvlp/cpp/code/upp/git/uppsrc/Core/SSL/Util.cpp:(.text.startup+0x13): undefined reference to `MemDiagCls::~MemDiagCls()' ...
Novo wrote on Thu, 20 March 2025 06:17 Interestingly, I tried to compile TheIDE with a USEMALLOC flag and got a result below. Linking... /bin/x86_64-unknown-linux-gnu-ld: /home/xxx/dvlp/cpp/code/upp/out/Core/SSL/CLANGcpp17um.Debug.Debug_Full.Gui.Shared/Util.o: in function `__cxx_global_var_init': /home/xxx/dvlp/cpp/code/upp/git/uppsrc/Core/Core.h:426:(.text.startup+0xc): undefined reference to `MemDiagCls::MemDiagCls()' /bin/x86_64-unknown-linux-gnu-ld: /home/xxx/dvlp/cpp/code/upp/out/Core/SSL/CLANGcpp17um.Debug.Debug_Full.Gui.Shared/Util.o: in function `__cxx_global_var_init': /home/xxx/dvlp/cpp/code/upp/git/uppsrc/Core/SSL/Util.cpp:(.text.startup+0x13): undefined reference to `MemDiagCls::~MemDiagCls()' ... There was a related bug in util.cpp, but not this one... Anyway, after fixing it, I have checked on all 3 platforms. So I guess please retry with master.
Novo wrote on Thu, 20 March 2025 05:47 I checked TheIDE with valgrind (debug version of TheIDE + open the ide package). A result is attached. I ran valgrind three times and each time result was different. This doesn't look good to me. I doubt that this is a problem with clangd itself. Checked our code, I do not see anything wrong with it... And it is really simple really: CXCursor cursor = clang_getTranslationUnitCursor(tu); pp_id = clang_getCursorPrintingPolicy(cursor); pp_pretty = clang_getCursorPrintingPolicy(cursor); for(int i = 0; i <= CXPrintingPolicy_LastProperty; i++) { clang_PrintingPolicy_setProperty(pp_id, (CXPrintingPolicyProperty)i, 0); clang_PrintingPolicy_setProperty(pp_pretty, (CXPrintingPolicyProperty)i, 0); } for(CXPrintingPolicyProperty p : { CXPrintingPolicy_SuppressSpecifiers, CXPrintingPolicy_SuppressTagKeyword, CXPrintingPolicy_SuppressUnwrittenScope, CXPrintingPolicy_SuppressInitializers, CXPrintingPolicy_SuppressStrongLifetime, CXPrintingPolicy_SuppressLifetimeQualifiers, CXPrintingPolicy_SuppressTemplateArgsInCXXConstructors, CXPrintingPolicy_TerseOutput, CXPrintingPolicy_SuppressImplicitBase, #ifndef UBUNTU2204_WORKAROUND CXPrintingPolicy_FullyQualifiedName, #endif CXPrintingPolicy_Bool }) clang_PrintingPolicy_setProperty(pp_id, p, 1); clang_PrintingPolicy_setProperty(pp_pretty, CXPrintingPolicy_TerseOutput, 1); clang_PrintingPolicy_setProperty(pp_pretty, CXPrintingPolicy_Bool, 1); clang_PrintingPolicy_setProperty(pp_pretty, CXPrintingPolicy_SuppressScope, 1); initialized = true; clang_visitChildren(cursor, clang_visitor, this); <<<<<<<<<<<<<<<< valgrind problem So the only input is 'tu', the rest are legal libclang calls. And checking the rest of code, 'tu' is either nullptr or result of translate.... Mirek
mirek wrote on Thu, 20 March 2025 04:17 Checked our code, I do not see anything wrong with it... In such case this is a problem with clangd I tried to double-check that with CLANG sanitizers but bumped into a problem with USEMALLOC ...
mirek wrote on Thu, 20 March 2025 03:58 Anyway, after fixing it, I have checked on all 3 platforms. So I guess please retry with master. Below is what I'm getting now. Linking... /bin/x86_64-unknown-linux-gnu-ld: /home/xxx/dvlp/cpp/code/upp/out/Core/SSL/CLANGcpp17um.Debug.Debug_Full.Gui.Shared/Util.o: in function `__cxx_global_var_init': /home/xxx/dvlp/cpp/code/upp/git/uppsrc/Core/Core.h:426:(.text.startup+0xc): undefined reference to `MemDiagCls::MemDiagCls()' /bin/x86_64-unknown-linux-gnu-ld: /home/xxx/dvlp/cpp/code/upp/out/Core/SSL/CLANGcpp17um.Debug.Debug_Full.Gui.Shared/Util.o: in function `__cxx_global_var_init': /home/xxx/dvlp/cpp/code/upp/git/uppsrc/Core/SSL/Util.cpp:(.text.startup+0x13): undefined reference to `MemDiagCls::~MemDiagCls()' /bin/x86_64-unknown-linux-gnu-ld: /home/xxx/dvlp/cpp/code/upp/out/Core/SSL/CLANGcpp17um.Debug.Debug_Full.Gui.Shared/InitExit.o: in function `Upp::SslFree(void*, char const*, int)': /home/xxx/dvlp/cpp/code/upp/git/uppsrc/Core/SSL/InitExit.cpp:41:(.text+0x3d7): undefined reference to `Upp::GetMemoryBlockSize(void*)' /bin/x86_64-unknown-linux-gnu-ld: /home/xxx/dvlp/cpp/code/upp/out/Core/SSL/CLANGcpp17um.Debug.Debug_Full.Gui.Shared/InitExit.o: in function `__cxx_global_var_init': /home/xxx/dvlp/cpp/code/upp/git/uppsrc/Core/Core.h:426:(.text.startup+0xc): undefined reference to `MemDiagCls::MemDiagCls()' /bin/x86_64-unknown-linux-gnu-ld: /home/xxx/dvlp/cpp/code/upp/out/Core/SSL/CLANGcpp17um.Debug.Debug_Full.Gui.Shared/InitExit.o: in function `__cxx_global_var_init': /home/xxx/dvlp/cpp/code/upp/git/uppsrc/Core/SSL/InitExit.cpp:(.text.startup+0x13): undefined reference to `MemDiagCls::~MemDiagCls()' /bin/x86_64-unknown-linux-gnu-ld: /home/xxx/dvlp/cpp/code/upp/out/Core/SSL/CLANGcpp17um.Debug.Debug_Full.Gui.Shared/Socket.o: in function `__cxx_global_var_init': /home/xxx/dvlp/cpp/code/upp/git/uppsrc/Core/Core.h:426:(.text.startup+0xc): undefined reference to `MemDiagCls::MemDiagCls()' /bin/x86_64-unknown-linux-gnu-ld: /home/xxx/dvlp/cpp/code/upp/out/Core/SSL/CLANGcpp17um.Debug.Debug_Full.Gui.Shared/Socket.o: in function `__cxx_global_var_init': /home/xxx/dvlp/cpp/code/upp/git/uppsrc/Core/SSL/Socket.cpp:(.text.startup+0x13): undefined reference to `MemDiagCls::~MemDiagCls()' /bin/x86_64-unknown-linux-gnu-ld: /home/xxx/dvlp/cpp/code/upp/out/Core/SSL/CLANGcpp17um.Debug.Debug_Full.Gui.Shared/P7S.o: in function `__cxx_global_var_init': /home/xxx/dvlp/cpp/code/upp/git/uppsrc/Core/Core.h:426:(.text.startup+0xc): undefined reference to `MemDiagCls::MemDiagCls()' /bin/x86_64-unknown-linux-gnu-ld: /home/xxx/dvlp/cpp/code/upp/out/Core/SSL/CLANGcpp17um.Debug.Debug_Full.Gui.Shared/P7S.o: in function `__cxx_global_var_init': /home/xxx/dvlp/cpp/code/upp/git/uppsrc/Core/SSL/P7S.cpp:(.text.startup+0x13): undefined reference to `MemDiagCls::~MemDiagCls()' /bin/x86_64-unknown-linux-gnu-ld: /home/xxx/dvlp/cpp/code/upp/out/Core/SSL/CLANGcpp17um.Debug.Debug_Full.Gui.Shared/SSL.icpp.o: in function `__cxx_global_var_init': /home/xxx/dvlp/cpp/code/upp/git/uppsrc/Core/Core.h:426:(.text.startup+0xc): undefined reference to `MemDiagCls::MemDiagCls()' /bin/x86_64-unknown-linux-gnu-ld: /home/xxx/dvlp/cpp/code/upp/out/Core/SSL/CLANGcpp17um.Debug.Debug_Full.Gui.Shared/SSL.icpp.o: in function `__cxx_global_var_init': /home/xxx/dvlp/cpp/code/upp/git/uppsrc/Core/SSL/SSL.icpp:(.text.startup+0x13): undefined reference to `MemDiagCls::~MemDiagCls()' clang++: error: linker command failed with exit code 1 (use -v to see invocation)
Novo wrote on Thu, 20 March 2025 17:23 mirek wrote on Thu, 20 March 2025 03:58 Anyway, after fixing it, I have checked on all 3 platforms. So I guess please retry with master. Below is what I'm getting now. Linking... /bin/x86_64-unknown-linux-gnu-ld: /home/xxx/dvlp/cpp/code/upp/out/Core/SSL/CLANGcpp17um.Debug.Debug_Full.Gui.Shared/Util.o: in function `__cxx_global_var_init': /home/xxx/dvlp/cpp/code/upp/git/uppsrc/Core/Core.h:426:(.text.startup+0xc): undefined reference to `MemDiagCls::MemDiagCls()' /bin/x86_64-unknown-linux-gnu-ld: /home/xxx/dvlp/cpp/code/upp/out/Core/SSL/CLANGcpp17um.Debug.Debug_Full.Gui.Shared/Util.o: in function `__cxx_global_var_init': /home/xxx/dvlp/cpp/code/upp/git/uppsrc/Core/SSL/Util.cpp:(.text.startup+0x13): undefined reference to `MemDiagCls::~MemDiagCls()' /bin/x86_64-unknown-linux-gnu-ld: /home/xxx/dvlp/cpp/code/upp/out/Core/SSL/CLANGcpp17um.Debug.Debug_Full.Gui.Shared/InitExit.o: in function `Upp::SslFree(void*, char const*, int)': /home/xxx/dvlp/cpp/code/upp/git/uppsrc/Core/SSL/InitExit.cpp:41:(.text+0x3d7): undefined reference to `Upp::GetMemoryBlockSize(void*)' /bin/x86_64-unknown-linux-gnu-ld: /home/xxx/dvlp/cpp/code/upp/out/Core/SSL/CLANGcpp17um.Debug.Debug_Full.Gui.Shared/InitExit.o: in function `__cxx_global_var_init': /home/xxx/dvlp/cpp/code/upp/git/uppsrc/Core/Core.h:426:(.text.startup+0xc): undefined reference to `MemDiagCls::MemDiagCls()' /bin/x86_64-unknown-linux-gnu-ld: /home/xxx/dvlp/cpp/code/upp/out/Core/SSL/CLANGcpp17um.Debug.Debug_Full.Gui.Shared/InitExit.o: in function `__cxx_global_var_init': /home/xxx/dvlp/cpp/code/upp/git/uppsrc/Core/SSL/InitExit.cpp:(.text.startup+0x13): undefined reference to `MemDiagCls::~MemDiagCls()' /bin/x86_64-unknown-linux-gnu-ld: /home/xxx/dvlp/cpp/code/upp/out/Core/SSL/CLANGcpp17um.Debug.Debug_Full.Gui.Shared/Socket.o: in function `__cxx_global_var_init': /home/xxx/dvlp/cpp/code/upp/git/uppsrc/Core/Core.h:426:(.text.startup+0xc): undefined reference to `MemDiagCls::MemDiagCls()' /bin/x86_64-unknown-linux-gnu-ld: /home/xxx/dvlp/cpp/code/upp/out/Core/SSL/CLANGcpp17um.Debug.Debug_Full.Gui.Shared/Socket.o: in function `__cxx_global_var_init': /home/xxx/dvlp/cpp/code/upp/git/uppsrc/Core/SSL/Socket.cpp:(.text.startup+0x13): undefined reference to `MemDiagCls::~MemDiagCls()' /bin/x86_64-unknown-linux-gnu-ld: /home/xxx/dvlp/cpp/code/upp/out/Core/SSL/CLANGcpp17um.Debug.Debug_Full.Gui.Shared/P7S.o: in function `__cxx_global_var_init': /home/xxx/dvlp/cpp/code/upp/git/uppsrc/Core/Core.h:426:(.text.startup+0xc): undefined reference to `MemDiagCls::MemDiagCls()' /bin/x86_64-unknown-linux-gnu-ld: /home/xxx/dvlp/cpp/code/upp/out/Core/SSL/CLANGcpp17um.Debug.Debug_Full.Gui.Shared/P7S.o: in function `__cxx_global_var_init': /home/xxx/dvlp/cpp/code/upp/git/uppsrc/Core/SSL/P7S.cpp:(.text.startup+0x13): undefined reference to `MemDiagCls::~MemDiagCls()' /bin/x86_64-unknown-linux-gnu-ld: /home/xxx/dvlp/cpp/code/upp/out/Core/SSL/CLANGcpp17um.Debug.Debug_Full.Gui.Shared/SSL.icpp.o: in function `__cxx_global_var_init': /home/xxx/dvlp/cpp/code/upp/git/uppsrc/Core/Core.h:426:(.text.startup+0xc): undefined reference to `MemDiagCls::MemDiagCls()' /bin/x86_64-unknown-linux-gnu-ld: /home/xxx/dvlp/cpp/code/upp/out/Core/SSL/CLANGcpp17um.Debug.Debug_Full.Gui.Shared/SSL.icpp.o: in function `__cxx_global_var_init': /home/xxx/dvlp/cpp/code/upp/git/uppsrc/Core/SSL/SSL.icpp:(.text.startup+0x13): undefined reference to `MemDiagCls::~MemDiagCls()' clang++: error: linker command failed with exit code 1 (use -v to see invocation) There must be some difference. What exactly is the host / build method / settings?
mirek wrote on Thu, 20 March 2025 18:10 There must be some difference. What exactly is the host / build method / settings? Host: Void Linux glibc (this is a rolling distro). Clang v17.0.6. Build method: attached Build command: umk uppsrc ide CLANGcpp17um -busa umk version: 17795 This build method was made long time ago, but it looks OK to me.
It turned out that address sanitizer doesn't require USEMALLOC ... Compilation command: umk uppsrc ide CLANGcpp17asan -busa A result is attached. EDITED: I guess this error happens because USEMALLOC is still required ...
Well, replacing 'COMMON_FLAGS = ".USEMALLOC";' with 'COMMON_FLAGS = "USEMALLOC";' fixed problem with linking. Weird.
This is what I've got after I enabled USEMALLOC with address sanitizer.
Memory sanitizer. This one looks weird because sanitizers are able to instrument only code they compile (unlike valgrind). But still. It is what it is.
On the positive side: a Safe Stack Sanitizer didn't report any problem
Can you send me .bms? (I could figure it out but it would be faster if you did) Mirek
mirek wrote on Fri, 21 March 2025 02:53 Can you send me .bms? (I could figure it out but it would be faster if you did) Mirek I made these bm-files several years ago. Probably, they can be improved.
I installed missing llvm tools and got better asan and msan logs. I also attached an improved CLANGcpp17asan.bm.
Painter/Rasterizer.cpp:318:10: runtime error: left shift of negative value -160 - this is interestingly no more error in C++20 (and ubsan agrees)... (I am adding this note here as I expect you to retest after I am finished fixing).
I have fixed everything I could. Unfortunately there are tons of leaks in gtk/fontconfig, unitialized variables etc. outside my control. Also thread sanitizer thinks that malloc/free implementation is wrong Mirek
mirek wrote on Sat, 22 March 2025 03:31 Painter/Rasterizer.cpp:318:10: runtime error: left shift of negative value -160 - this is interestingly no more error in C++20 (and ubsan agrees)... (I am adding this note here as I expect you to retest after I am finished fixing). I attached what I'm getting with my compiler. Left shift is still there ...
mirek wrote on Sat, 22 March 2025 06:30 I have fixed everything I could. Unfortunately there are tons of leaks in gtk/fontconfig, unitialized variables etc. outside my control. Also thread sanitizer thinks that malloc/free implementation is wrong Mirek Thank you! IMHO, it makes sense to add build methods with sanitizers to release distros so people won't need to reinvent them.
Novo wrote on Sun, 23 March 2025 05:38 mirek wrote on Sat, 22 March 2025 03:31 Painter/Rasterizer.cpp:318:10: runtime error: left shift of negative value -160 - this is interestingly no more error in C++20 (and ubsan agrees)... (I am adding this note here as I expect you to retest after I am finished fixing). I attached what I'm getting with my compiler. Left shift is still there ... Either your clang version does not know about it or you have not changed the build method to C++20... (When I did, it got fixed). Mirek
mirek wrote on Sun, 23 March 2025 02:56 Either your clang version does not know about it or you have not changed the build method to C++20... (When I did, it got fixed). Mirek Yes, changing cpp version to 20 eliminates the problem. But current cpp version used by UPP is 17 ...
Novo wrote on Sun, 23 March 2025 20:19 mirek wrote on Sun, 23 March 2025 02:56 Either your clang version does not know about it or you have not changed the build method to C++20... (When I did, it got fixed). Mirek Yes, changing cpp version to 20 eliminates the problem. But current cpp version used by UPP is 17 ... Well, I suggest you google the issue up... It was defined in practice and widely used for ages now, except the standard lagged behind... Mirek
mirek wrote on Sun, 23 March 2025 15:37 Well, I suggest you google the issue up... It was defined in practice and widely used for ages now, except the standard lagged behind... Mirek I propose a different way of fixing this problem: a pull request. New command to check: umk tutorial CoreTutorial CLANGcpp17ubsan -bus Result is attached.
Novo wrote on Mon, 24 March 2025 04:51 mirek wrote on Sun, 23 March 2025 15:37 Well, I suggest you google the issue up... It was defined in practice and widely used for ages now, except the standard lagged behind... Mirek I propose a different way of fixing this problem: a pull request. New command to check: umk tutorial CoreTutorial CLANGcpp17ubsan -bus Result is attached. a) good to know b) you are adding a couple of completely unnecessarry and confusing lines to the project c) AFAIK you can as well do -fsanitize=no-shift-base if you insist on using C++17 definition (but why you insist on that is beyond me. we will probably be moving C++20 in 3 years anyway)