After a lot of thinking I believe that the only plausible explanation is that another thread calls Iml::Reset somehow.

Can you crash it and then send backtrace of ALL threads?

Quote:

After a lot of thinking I believe that the only plausible explanation is that another thread calls Iml::Reset somehow.

Can you crash it and then send backtrace of ALL threads?

Thank you for your efforts. Will do, but this weekend. I am away from my computer today.


Best regards,
Oblivion

void Iml::Reset()
{
	for(IImage& m : map)
		m.loaded = false;
}

Also, can you try with this attempt at fix (but it would explain it just partly, still would like to have bt of all threads after the crash without the fix):

void Iml::Reset()
{
for(IImage& m : map)
m.loaded = false;
}

(maybe those specific assemblies have custom icons to display in package list?)

Anyway, from backtraces it looks like indexer/libclang is running full steam. Can you try with assist++ off?

and perhaps separately try setting Image icon = Null;

Quote:

(maybe those specific assemblies have custom icons to display in package list?)

No.

Quote:

Anyway, from backtraces it looks like indexer/libclang is running full steam. Can you try with assist++ off?

I have attached the logs. However, I noticed that it crashes less frequently when the indexer/assist++ is off.
Quote:

and perhaps separately try setting Image icon = Null;

Will try.

Best regards,
Oblivion

And the last obligatory question: It really is crashing only on opening new main package, right?

And BTW, when you test, do you test like for(;;) { Ctrl+M, Esc } or like for(;;) { Ctrl+M, select package, Enter } ?

And the last obligatory question: It really is crashing only on opening new main package, right?
However, I'm suspecting this is a compiler error now. (maybe O3 optimization level related?). I'll try other options (O2 and GCC), report back asap.

	for(int i = 0; i < packages.GetCount(); i++) {
		const PkInfo& pkg = packages[i];
		DDUMP(IdeImg::GetCount());

//		alist.SetDisplay(alist.GetCount() - 1, 0, pkg.main ? bpd : pd);

Ok, I will do that later today.

But in the meantime I have found out that TheIDE compiled with GCC with the same level of optimization (O3) didn't crash, however I tried since yesterday (on the same machine/setup). Not once.
It does "appear" to be a compiler bug, but with the above tests -hopefully- we'll see.


Best regards,
Oblivion

Maybe we should move to gcc?

mirek wrote on Sun, 20 October 2024 10:55

Maybe we should move to gcc?

Hi,

I hope that 'moving to gcc' does not mean dropping support for clang.

My policy with platforms (including compilers) is to try to support more than one. When intermittent issues appear on one compiler, it is then easier to switch to another working compiler until the issue is resolved. When the code base is built to be compatible with MSC, CLANG and GCC (avoiding the known weak spots and/or bugs of each), the capability to handle new issues and avoid down time in such situations is far better.

Best regards,

Tom

if clang++ --version >/dev/null; then
	echo $UMK ./uppsrc ide CLANG -brs ./theide
	$UMK ./uppsrc ide CLANG -brs ./theide
	$UMK ./uppsrc umk CLANG -brs ./umk
else
	echo $UMK ./uppsrc ide GCC -brs ./theide
	$UMK ./uppsrc ide GCC -brs ./theide
	$UMK ./uppsrc umk GCC -brs ./umk
fi

if g++ --version >/dev/null; then
	echo $UMK ./uppsrc ide GCC -brs ./theide
	$UMK ./uppsrc ide GCC -brs ./theide
	$UMK ./uppsrc umk GCC -brs ./umk
else
	echo $UMK ./uppsrc ide CLANG -brs ./theide
	$UMK ./uppsrc ide CLANG -brs ./theide
	$UMK ./uppsrc umk CLANG -brs ./umk
fi

Hello Mirek,

I have attached the new logs.


Assuming that this is a compiler bug, I still wouldn't change the default on Linux. My reasons:

1) I didn't encounter it anywhere else. I have a lot of apps, tests etc, some have heavy inlining, and built with the same clang config. They are all stable (at least, they have yet to crash because of a really puzzling error.)
2) I tend to use ArchLinux on my machines (and other distros on VM), which ships the latest LLVM/clang, so this might be a bug in the latest version of the compiler. (At least, I did not have such crashes several months ago.)
3) GCC has significantly slower compilation speed.
4) I don't know of anyone else complaining about this bug, and I am fine with using the GCC build, it works as expected.


Best regards,

Oblivion

======== LOAD
i = 39
i = 39
i = 39
i = 39
i = 39
i = 335
i = 335

What is clang --version?

clang version 18.1.8
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

I have also pushed a bunch of changes which I suppose should fix this. Can you try master?

Should we file this in clang's bugzilla?

Quote:

What is clang --version?

clang version 18.1.8
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

Quote:

I have also pushed a bunch of changes which I suppose should fix this. Can you try master?

If you mean commit 509e32c, I just tried it and no, unfortunately, TheIDE is still crashing with the same behaviour.

Quote:

Should we file this in clang's bugzilla?

At this point, yes.