valgrind explains everything.

Novo wrote on Sun, 18 September 2022 21:23

valgrind explains everything.

While it is definitely a good idea, only one of these errors seems libclang related and fixable and it happens on theide exit. Anyway, now fixed.

That said, everything valigrind says is worth investigation. I was able to fix many of these issues (in master now), unfortunately it looks like majority of remaining problems is cairo related (these happen when we are reading images from gtk).

Any help identifying the cause(s) is welcome.

Mirek

valgrind --track-origins=yes --log-file=memchk.txt ~/dvlp/cpp/code/upp/out/CLANG.Debug.Debug_Full.Gui.Shared/ide

Thanks a lot! TheIde doesn't crash anymore.

mirek wrote on Tue, 20 September 2022 07:09

Novo wrote on Sun, 18 September 2022 21:23

valgrind explains everything.

While it is definitely a good idea, only one of these errors seems libclang related and fixable and it happens on theide exit. Anyway, now fixed.

That said, everything valigrind says is worth investigation. I was able to fix many of these issues (in master now), unfortunately it looks like majority of remaining problems is cairo related (these happen when we are reading images from gtk).

Any help identifying the cause(s) is welcome.

Mirek

Thanks a lot! TheIde doesn't crash anymore.
I personally do not see any cairo problems. I guess Void Linux has a better valgrind exceptions list.
The only problem I do see is an uninitialized value in Ide::Serialize.
Interestingly, this problem depends on when you close TheIde.
I guess this data is uninitialized during libclang indexing/reindexing.

I am getting that one (in Ide::Serialize) too; my guts feeling is that it is not related to libclang

I am getting that one (in Ide::Serialize) too; my guts feeling is that it is not related to libclang, just some old serialisation bug like forgotten unitialised variable. Want to hunt that down, but it is time consuming....

What about those "_dl_catch_exception " things? Does not look like U++ fault, right?

I've got a different call stack with Ide::Serialize.
Maybe it will help to locate a problem.

Thanks, fixed.

/home/buildbot/worker/l-upp/build/uppsrc/Core/SMTP/Smtp.cpp:457:2: error: expected expression
        DDUMP(GetMessage(true));
        ^
/home/buildbot/worker/l-upp/build/uppsrc/Core/Diag.h:159:26: note: expanded from macro 'DDUMP'
#define DDUMP(x)         @ // To clean logs after debugging, this produces error in release mode
                         ^
1 error generated.

Novo wrote on Wed, 21 September 2022 01:56

I've got a different call stack with Ide::Serialize.
Maybe it will help to locate a problem.

Thanks, fixed. (Unfortunately it was complete non-bug that could not have influenced anything real, just unitialized variable that is never used again).

mirek wrote on Wed, 21 September 2022 04:52

Novo wrote on Wed, 21 September 2022 01:56

I've got a different call stack with Ide::Serialize.
Maybe it will help to locate a problem.

Thanks, fixed. (Unfortunately it was complete non-bug that could not have influenced anything real, just unitialized variable that is never used again).

I do see two problems with valgrind messages:

1) Tons of "uninitialized value" messages hide real problems.
2) Nobody will use Upp with commercial apps for a very simple reason: who knows what kind of problems can be caused by these "uninitialized values".

IMHO, Upp should be checked with all available valgrind tools and all available sanitizers. At least before release.

Upp version: 16443

OS: Ubuntu 22.04.1 LTS x86_64
CPU: Intel i7-8650U (8) @ 4.200GHz
GPU: Intel UHD Graphics 620
Memory: 3757MiB / 15875MiB

I don't know how much improvement we can expect in, say half an year's time. At the moment, I Ctrl+Left click on a member function in a moderately complex project, the parsing starts and goes on for ever. At least 30 minutes past and no idea how much longer it's going to take. In contrast, it used to work so smoothly.

Theoretically moving to libclang is the right thing to do, but there is a huge chance it may render theide completely useless.

Something might not be right.

Nah, Mirek, I don't feel I'm owed an explanation

It was not meant specifically for you...

In your case I remember complaining about headers. Do they work now?

As for old libclang... I can put limit for minimal version, e.g. libclang 10 (I am quite sure that one works), what do you think?

Is autocomplete working?

Fatal Error!
Invalid memory access!

ps2: Now even after I remove'd libclang-dev, theide in upp version 16443 won't work. You don't even need to type in anything, it will crash itself with invalid memory access in just a few seconds(when background parsing threads start). It looks like a libclang version problem. For now, I will go back to upp version 16303 on which autocomplete works fine.

sudo bash -c "$(wget -O - https://apt.llvm.org/llvm.sh)"

before assist_cursor is set. If I move that block of code after the pos set it shows the files but it has strange index numbers next to the icons. <- never mind, that appears to be for debugging purposes and doesn't appear in release mode.

Otherwise, thanks for spotting the bug. Does include assist work now?

Mirek

Lance wrote on Sat, 24 September 2022 15:00

ps2: Now even after I remove'd libclang-dev, theide in upp version 16443 won't work. You don't even need to type in anything, it will crash itself with invalid memory access in just a few seconds(when background parsing threads start). It looks like a libclang version problem. For now, I will go back to upp version 16303 on which autocomplete works fine.

I didn't try dev packages, I just uninstalled clang through package manager and ran

sudo bash -c "$(wget -O - https://apt.llvm.org/llvm.sh)"

to bring everything to clang-15, including libclang. Should work with debian/apt systems.

Hello Lance,

Please remove cahce and cofnig directories:

rm -rf ${upp_dir}/.cache
rm -rf ${upp_dir}/.config

It should help.

I know that in the past we eliminated some migration issues related to new clang implementation, but it seems that there is something from the old installation that is causing crash.

Klugier

Hello Lance,

Could you open ide project and build it in debug mode. After that in TheIDE in debug mode (under debugger) open examples/Days package. Thanks to that we should be able to obtain callstack of the crash.

If you have trouble with opening uppsrc/ide package due to crash in TheIDE, disable clang parsing in Settings (Assist tab and first option from the left). Screenshot below:


Klugier

Hello Lance,

OK, I see where the problem is. We are dynamically loading libclang without notify the user about the actions of this operation. It must change and in situation when we do not detect it we should show error and siabled parsing...

Here is the code in TheIDE (ide/main.cpp):

#ifdef PLATFORM_POSIX
void TryLoadLibClang() // Should return bool...
{
	String libdir = TrimBoth(Sys("llvm-config --libdir"));
	if(LoadLibClang(libdir + "/libclang.so"))
		return;
	if(LoadLibClang("/usr/lib/libclang.so"))
		return;
	for(int i = 20; i >= 10; i--)
		if(LoadLibClang("/usr/lib/llvm-" + AsString(i) + "/lib/libclang.so"))
			return;
}
#endif

#ifdef flagMAIN
GUI_APP_MAIN
#else
void AppMain___()
#endif
{
#ifdef PLATFORM_POSIX
	TryLoadLibClang(); // If it fails... just notrmal execution without any notification or error. However user will now if libclang is conffigured correctly?
#endif
        // Above operation fails and we are starting to use libclang, it can not end good...

The above code must be fixed and then you can try to run TheIDE. If you do not have correctly set libclang then you should see the error.
-------------------
Edit: In general I assume that for your configuration there is a problem with finding libclang.so and lack of this library is causing crash.

Klugier