View Issue Details

IDProjectCategoryView StatusLast Update
0003224The Dark ModCodingpublic13.08.2019 03:45
Reportergrayman Assigned Tograyman  
PriorityhighSeveritycrashReproducibilityalways
Status resolvedResolutionfixed 
Product VersionTDM 1.08 
Target VersionTDM 2.00 
Summary0003224: TheDarkMod.exe crashes after updating a 1.07 installation to 1.08
DescriptionIf a 1.07 darkmod/gamex86.dll is present, and darkmod is updated to 1.08, TheDarkMod.exe will fail to replace the 1.07 DLL with the 1.08 DLL, causing a crash.

TheDarkMod.exe must overwrite the old one with the new one.
TagsNo tags attached.

Relationships

related to 0005042 resolvedstgatilov Timestamps fiasco: Unix vs DOS, local vs UTC 

Activities

angua

angua

09.09.2012 05:36

manager   ~0004815

The old behavior was:
if there is a dll next to the exe (in the doom3 folder): the exe takes this one (this was convenient for developers)
else: extract dll from pk4 into darkmod folder and use this one

So, now the exe is now sitting in the darkmod folder and finds a dll, so it thinks it can use this one and doesn't extract it from the pk4.

If we let the exe always extract the dll from the pk4, this will be inconvenient for developers. A possibility would be to use time stamps or similar.
Another suggestion would be to let the updater handle the issue: let the updater extract the dll from the pk4 into the darkmod folder, disable the code that lets the exe extract it (at least on windows, I don't know what happens on Linux).
tels

tels

14.09.2012 07:10

reporter   ~0004828

Why is it inconvienient for developers? At least on linux, when you rebuild the DLL, it gets put as ".so" into the directory, as well as stuffed into a .PK4.

So regardless of wether it is extracted or not, the new DLL is used. Can't the build process on Windows not be changed to do the same?
taaaki

taaaki

26.09.2012 19:25

administrator   ~0004852

Quick fix implemented in SVN revision 0005577. Existing game dll/so in the darkmod/ directory is ignored and the game dll/so from tdm_game0x.pk4 is extracted and loaded on startup. A more refined fix will be implemented in SVN for future releases.

I will mark this issue closed when the refined fix is implemented (whether that be a simple build process change for the Windows project or adding additional logic to the game dll/so loading code).
grayman

grayman

16.10.2012 15:18

viewer   ~0004919

I'm moving this from 1.08 to 1.09.

taaaki's temporary fix solves the problem for 1.08.

His long-term fix will go in later.
taaaki

taaaki

26.03.2013 04:02

administrator   ~0005240

darkmod_src revision 5723 - A timestamp check has been added to the code that determines whether to use the existing game dll/so in the executable directory or the one in the game pak file.

I will mark this issue resolved if there are no issues reported in a week or two.
taaaki

taaaki

08.06.2013 20:45

administrator   ~0005540

No issues that I am aware of, so closing this.
taaaki

taaaki

10.06.2013 15:10

administrator   ~0005549

Seems that all is not well.

http://forums.thedarkmod.com/topic/14840-more-filesystem-changes-yay/page__view__findpost__p__312950
taaaki

taaaki

04.08.2013 18:57

administrator   ~0005962

I can't manage to reproduce this. Every time I throw in a gamedll that is older than the one in the pk4, the new LoadDLL/FindDLL code seems to pick it up and extract the dll from the file. How many other people have experienced the dll issue?

I think this will need to be thoroughly tested during the freeze.
taaaki

taaaki

04.08.2013 19:39

administrator   ~0005963

Any help with conditions to reproduce this would be appreciated.
grayman

grayman

04.08.2013 19:53

viewer   ~0005964

We'll have to test this during the freeze, when we have a package we can load over the top of a 1.08 installation.
Springheel

Springheel

10.08.2013 21:31

administrator   ~0005995

Last edited: 10.08.2013 21:31

It seems like this is still happening.

--------------------
I've just ran the updater under Windows 7 64bit. I've made a differential update from 1.08, with the keep mirrors setting enabled. The update itself worked like a charm. But if I try to run the game via the TheDarkMod.exe, the game crashes.

---------------------
Was there a gamex86.dll sitting around after the upgrade?

If so, delete it and try restarting TDM.
------------------------

Allright. That was the problem.

EDIT: If this can cause such problems, it may be a good idea if the updater/installer would check for such a file and delete it if existent. I guess most people will do a differential update after 2.0 release and may miss this hint.

taaaki

taaaki

10.08.2013 21:35

administrator   ~0005996

Thing is, the current TheDarkMod.exe looks at the file timestamps for the existing gamex86.dll and the one inside the pk4. It will then make a decision to extract/overwrite the existing dll based on which has the later timestamp. I'd like to find out if other people experience the same issue. If so, it might be a problem with the timestamp comparison.
taaaki

taaaki

10.08.2013 21:36

administrator   ~0005997

That being said. It might make life easier to just get the updater to delete gamex86.dll / gamex86.so regardless.
Springheel

Springheel

20.08.2013 14:03

administrator   ~0006067

What is the expected behaviour here? I just ran tdm_updater yesterday and it downloaded some new files, but it did not delete gamex86.dll. Is it supposed to?
grayman

grayman

20.08.2013 14:47

viewer   ~0006070

Yes. I'm moving the code that does the removal so that it will be done regardless what type of installation/upgrade you do.
Springheel

Springheel

01.09.2013 21:35

administrator   ~0006138

I forgot to check on the last update if this happened or not.
grayman

grayman

01.09.2013 22:04

viewer   ~0006139

Fixed in the 8/20 build.
Springheel

Springheel

02.09.2013 15:50

administrator   ~0006142

Just checked on the last update and it was deleted successfully.

Issue History

Date Modified Username Field Change
07.09.2012 22:44 grayman New Issue
07.09.2012 22:44 grayman Status new => assigned
07.09.2012 22:44 grayman Assigned To => taaaki
09.09.2012 05:36 angua Note Added: 0004815
14.09.2012 07:10 tels Note Added: 0004828
26.09.2012 19:25 taaaki Note Added: 0004852
16.10.2012 15:18 grayman Note Added: 0004919
16.10.2012 15:18 grayman Target Version TDM 1.08 => TDM 2.00
26.03.2013 04:02 taaaki Note Added: 0005240
08.06.2013 20:45 taaaki Note Added: 0005540
08.06.2013 20:45 taaaki Status assigned => resolved
08.06.2013 20:45 taaaki Resolution open => fixed
10.06.2013 15:10 taaaki Note Added: 0005549
10.06.2013 15:10 taaaki Status resolved => assigned
04.08.2013 18:57 taaaki Note Added: 0005962
04.08.2013 19:39 taaaki Note Added: 0005963
04.08.2013 19:39 taaaki Status assigned => feedback
04.08.2013 19:53 grayman Note Added: 0005964
04.08.2013 19:53 grayman Status feedback => assigned
10.08.2013 21:31 Springheel Note Added: 0005995
10.08.2013 21:31 Springheel Note Edited: 0005995
10.08.2013 21:35 taaaki Note Added: 0005996
10.08.2013 21:36 taaaki Note Added: 0005997
20.08.2013 14:03 Springheel Note Added: 0006067
20.08.2013 14:47 grayman Note Added: 0006070
01.09.2013 21:35 Springheel Note Added: 0006138
01.09.2013 21:35 Springheel Assigned To taaaki => grayman
01.09.2013 21:35 Springheel Status assigned => feedback
01.09.2013 22:04 grayman Note Added: 0006139
01.09.2013 22:04 grayman Status feedback => assigned
02.09.2013 15:50 Springheel Note Added: 0006142
02.09.2013 15:50 Springheel Status assigned => feedback
02.09.2013 15:51 Springheel Status feedback => resolved
13.08.2019 03:45 stgatilov Relationship added related to 0005042