stgatilov

We never found what was the reason behind this issue. It broke after we started asking for GL 3.3 instead of GL 3.1, and it does not break in compatibility mode. I don't think it is easy to revert back to the old version, and not sure how to debug it either.

As far as I remember, TDM 2.09 requires OpenGL 3.3 to start. So either your OpenGL does not fit the requirement, or (as I guessed above) it has separate GL versions for core and deprecated profile. Perhaps version in core profile is newer than 3.3, but the version in deprecated profile is only 3.1 By the way, do you also have the problem with black screen in main menu and sound playing?

Wow! Given that 2.10 beta testing will most likely start at the beginning of December... it would be a busy month

Mmm... probably some Mesa-based open-source Linux drivers? Until recently, they did not support GL3+ with deprecated profile.

Then the same workaround should work: seta r_glCoreProfile "0" in darkmod.cfg It is a rather old graphics card, right?

I already gave debug symbols for the 2.09a release. They can be used for debugging, although doing it is not very obvious (optimizations make things messy). The source code for the latest release can be obtained from website: https://www.thedarkmod.com/sources/thedarkmod.2.09a.src.7z There is COMPILING.txt file inside, which explains how to build. It is pretty standard CMake build, so I guess you can edit CMakeLists.txt to disable optimization. P.S. Since I'll probably need to analyze other core dumps in future anyway, I'd be happy to try one more thing. @esme, could you please share your libc.so ?

I think you suffered a lot more than me to get to this point I'm disappointed if this comes to no end after so much effort. Yes, I'm surprised too. Do you know by any chance if your glibc was compiled with -fomit-frame-pointers ? One possible explanation is that your glibc build has no frame pointers (maybe all builds are done like this). I don't have debug symbols for it, so my gdb cannot push through glibc functions when doing stack trace (note that the crash happens inside free). You have debug information (I suppose it was installed with some of the packages, e.g. with gdb) of glibc, enough to make stack trace push through glibc functions and see TDM call stack. Anyway, I don't think it makes sense to fight with this mess. It's time to either forget about this problem until better circumstances, or try debugging over Skype or something like that (which would probably be lengthy and end nowhere too).

It did not help. I totally lost my faith in Linux core dumps. Also asked a question, maybe I'm doing something wrong: https://stackoverflow.com/questions/69189241/analyze-linux-core-dump-on-different-machine-threads-and-shared-libs

It seems that I also need libpthread.so.0.

Could you find libpthread_db.so.1 file on your machine and share it here? Pretty stupid thing of course, but I guess that's what I'll have to ask now from every user who creates a core dump

I see the same trash again. It turns out that in the damn Linux world, you cannot open core dump made on a machine with different glibc version if the program is multithreaded! At least that's how I understand the warning "Unable to find libthread_db matching inferior's thread library, thread debugging will not be available." I don't know how to fix that... to me it makes core dumps rather useless feature. I'm glad you have posted a stacktrace. At least I know where to look at.

I must admit I'm rather nooby in Linux development I looked into the dump, but could not get meaningful stack traces. It seems that TDM is killed by SIGABRT, and it seems that core dump contains state after handling the signal. This is quite strange because manuals say that gdb breaks on it by default. Maybe you could try again, but please execute "handle SIGABRT stop" in gdb before executing "run" ? Another approach is to get stack trace on your machine. Download debug symbols: get and unpack thedarkmod.x64.debug, put it just near thedarkmod.x64. Then run gdb ./thedarkmod.x64: you should see a message like this: Reading symbols from /mnt/hgfs/thedarkmod/darkmod_209/thedarkmod.x64.debug...done. Then execute "run" and reproduce the crash. After then execute "bt" in gdb: it should print meaningful stack trace. You can also switch between threads using "info threads" and "thread 1" / "thread 2" / ..., but I hope it won't be necessary.

Ehm... memory dumps are usually compressed very well. Just in case you submit another one

Both systems do not control OpenGL in any way, then only give "primary framebuffer" and control final image compositing. OpenGL rendering should work equally well on both systems. Maybe some specifics around compositing can add one excessive framebuffer copy in one of the cases, but it won't change much (except on integrated GPU maybe, which is too bad to play TDM comfortably).

Could it be changes by @nbohr1more ?

I think that's only problem is to find someone who will test them and commit. Languages always lag behind.

New version is available: dev16358-9588

I tried to decipher it but failed. There is another way to create core dump. Run the game under GDB: gdb ./thedarkmod.x64 Type "run" and enter to start program When the game crashes, gdb will most likely break Run command in GDB: generate-core-file

It is pointless: just tell people to build the whole solution. In fact, most people usually do it by default.

I think he built one project only (most likely DarkRadiant), and some core modules did not build. You can say that DarkRadiant project depends on SomeCoreModule project in the solution, so that the latter one will build automatically if you build the former one. UPDATE: On my daily job, there are several hundred projects in the solution, and some of the projects are intended for dynamic loading (i.e. you can load them in some tests which need them but not load in the others). So if I build only one project that I need, I have to later track down more projects that are used in the particular test, since dependencies are missing. And if I build the whole solution, then I can just go get some tea/coffee chat or pull out my sword... Unfortunately, inter-project dependencies are often not enough.

Removed the feature in svn revs 9587 and 16353.

I used NTFS Undelete in the past, although how much its free version is allowed to do might have changed already. Also, I'm not sure if recovering deleted file from SSD has any specifics... I think most importantly the tool must be suited for a specific filesystem used (i.e. NTFS on Windows).

The bad news is: the chance of recovering deleted files quickly reduces as you write more and more data to the same drive/partition, because deleted chunks can be reused for new data, at which moment the data is totally lost. You need to be extremely cautions and quick if you want to undelete something. If the partition contains OS, then it will most likely write lots of stuff quickly, making recovery even less likely. As for the button itself, I never understood why it exists in the first place. Maybe this is the remnant from the very first release, when savegames took hundreds of megabytes because all editor spawnargs for every alive entity were saved in them. Unless there are other opinions, let's delete the button.

Yes, the list you posted is only for the main game. The similar list for missions is in the missions database SVN (you can find it with repo-browser). It should not work this way. I think list of mirrors should be shuffled randomly, independently for each mission.

Crap... What if you just execute "crash" command in TDM console, will you get code dump then? Trying to understand what's going on straight on your machine won't be fun at all. I have uploaded debug symbols in case you have GDB skills. I will also try to reproduce the problem myself in Linux VM (in fact, I should have done it much earlier), but I don't have much hope on it. Also, you can try cleaning TDM directory --- maybe some old files cause the problem. As a rule of thumb, you can delete all files except *.pk4 and *.zip. After that, unpack contents of tdm_shared_stuff.zip or simply run tdm_installer. Note: I checked that your pk4/zip files are correct, but I cannot check the other files. For instance, delete currentfm.txt, startingmap.txt, maybe fms/missions.tdminfo (that would delete marks about which mission you have played). Clean install is also worth trying.