http://bugs.winehq.org/show_bug.cgi?id=18991
Summary: Sims 3 crash loading a Town Product: Wine Version: 1.1.23 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: blocker Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: otto_rey@yahoo.com.ar
Sims 3 crash loading a Town. Progress bar show 1/6 percent of complete, then exit prematurely without a msgbox.
No radomn, this happen Always
Tried with and without M$ DirectX Tried with and without PlayOnLinux Tried with ATI and NVIDIA Tried with Fedora 10 x86 and Fedora 11 x64 Tried with patched and unpatched 1.1.23 version
95% of test was made selecting Spanish as language, but tried English without luck.
http://bugs.winehq.org/show_bug.cgi?id=18991
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|blocker |normal
--- Comment #1 from Vitaliy Margolen vitaliy@kievinfo.com 2009-06-18 20:03:41 --- http://bugs.winehq.org/page.cgi?id=fields.html#bug_severity
Terminal output is where?
http://bugs.winehq.org/show_bug.cgi?id=18991
Pablo Marchant pamarca@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pamarca@gmail.com
--- Comment #2 from Pablo Marchant pamarca@gmail.com 2009-06-18 20:45:57 --- The terminal output is mostly filled by messages like this:
fixme:xinput:XInputGetState (1 0x256fca8) fixme:imm:ImmGetOpenStatus (0x2a9bf28): semi-stub fixme:imm:ImmGetOpenStatus (0x2a9bf28): semi-stub
This fills the output all the time, since I start the game, not just when it crashes. Now, near the time it crashes, it gives this error:
* Assertion at ....\mono\mono\metadata\icall.c:5454, condition `err' not met
then a lot of the same xinput, and then it crashes without further output...
http://bugs.winehq.org/show_bug.cgi?id=18991
Pablo Marchant pamarca@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #3 from Pablo Marchant pamarca@gmail.com 2009-06-18 20:47:17 --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #4 from Vitaliy Margolen vitaliy@kievinfo.com 2009-06-18 22:28:29 --- Please attach _complete_ terminal output as a text file.
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #5 from Dmitry Timoshkov dmitry@codeweavers.com 2009-06-18 22:30:02 --- (In reply to comment #2)
- Assertion at ....\mono\mono\metadata\icall.c:5454, condition `err' not met
Is that a .NET application?
http://bugs.winehq.org/show_bug.cgi?id=18991
Mark hughes markh789@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |markh789@gmail.com
--- Comment #6 from Mark hughes markh789@gmail.com 2009-06-19 00:54:28 --- (In reply to comment #5)
(In reply to comment #2)
- Assertion at ....\mono\mono\metadata\icall.c:5454, condition `err' not met
Is that a .NET application?
"* Assertion at ....\mono\mono\metadata\icall.c:5454, condition `err' not met" Comes to a few people when playing The Sims 3, I come to think that it may be from the wine source? Not to sure.
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #7 from Dmitry Timoshkov dmitry@codeweavers.com 2009-06-19 02:44:41 --- (In reply to comment #6)
Is that a .NET application?
"* Assertion at ....\mono\mono\metadata\icall.c:5454, condition `err' not met" Comes to a few people when playing The Sims 3, I come to think that it may be from the wine source? Not to sure.
No, that's not Wine source. might be Mono, that's why I'm asking if that's a .NET application provoking a bug in Mono.
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #8 from Mark hughes markh789@gmail.com 2009-06-19 07:22:07 --- (In reply to comment #7)
(In reply to comment #6)
Is that a .NET application?
"* Assertion at ....\mono\mono\metadata\icall.c:5454, condition `err' not met" Comes to a few people when playing The Sims 3, I come to think that it may be from the wine source? Not to sure.
No, that's not Wine source. might be Mono, that's why I'm asking if that's a .NET application provoking a bug in Mono.
Alright. I have no knowledge of the Wine source, I really need to have a look into it.
Back into it.. have you tried this onto another Linux distribution?
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #9 from Pablo Marchant pamarca@gmail.com 2009-06-19 10:30:53 --- This app requires the installation of dot net 2.0
Also, Ive tried this both on jaunty and karmic with the same results
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #10 from Pablo Marchant pamarca@gmail.com 2009-06-19 11:40:39 --- Created an attachment (id=21894) --> (http://bugs.winehq.org/attachment.cgi?id=21894) Terminal output
Attached the terminal output for the full run of the program.
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #11 from Pablo Marchant pamarca@gmail.com 2009-06-19 16:01:06 --- Just in case, the "Fallo de segmentación" at the end of my attached trace means "Segmentation fault".
http://bugs.winehq.org/show_bug.cgi?id=18991
landeel cleberdemattoscasali-wine@yahoo.com.br changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cleberdemattoscasali-wine@y | |ahoo.com.br
--- Comment #12 from landeel cleberdemattoscasali-wine@yahoo.com.br 2009-06-28 09:48:05 --- Same thing here. Kubuntu 8.04 X86_64, AMD X2 4200, Geforce 8500GT. I get a "* Assertion at ....\mono\mono\metadata\icall.c:5454, condition `err' not met" just before the crash.
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #13 from Dmitry Timoshkov dmitry@codeweavers.com 2009-07-09 11:10:40 --- That's pretty strange to see mono\mono\metadata\icall.c in the output if you have installed .net runtime.
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #14 from Mark hughes markh789@gmail.com 2009-07-11 03:30:57 --- Could I ask, do you all have AMD?
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #15 from Pablo Marchant pamarca@gmail.com 2009-07-11 12:04:43 --- I have an AMD X2 dual core TK-53
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #16 from Ahmed Elmahdawy aa_mahdawy@hotmail.com 2009-07-11 16:18:59 --- Created an attachment (id=22330) --> (http://bugs.winehq.org/attachment.cgi?id=22330) Wine TS3 Town Crash Log [Bug 18991]
Here's a full TS3.exe log.
http://bugs.winehq.org/show_bug.cgi?id=18991
Ahmed Elmahdawy aa_mahdawy@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |aa_mahdawy@hotmail.com
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #17 from landeel cleberdemattoscasali-wine@yahoo.com.br 2009-07-12 19:34:32 --- I have an AMD X2 4800, 4 GB RAM, with a GeForce 8500 GT.
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #18 from Otto Rey otto_rey@yahoo.com.ar 2009-07-13 15:57:10 --- Me too:
Athlon 64 X2 in my Notebook Athlon 2500+ in my Desktop
http://bugs.winehq.org/show_bug.cgi?id=18991
Jo Shields directhex@apebox.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |directhex@apebox.org
--- Comment #19 from Jo Shields directhex@apebox.org 2009-07-16 20:04:34 --- These messages come FROM THE GAME. It's nothing to do with any installed .NET runtimes.
TS3.exe contains an embedded copy of Mono, which is used for pretty much the entire game scripting engine.
See http://www2.apebox.org/wordpress/linux/118/
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #20 from landeel cleberdemattoscasali-wine@yahoo.com.br 2009-07-16 20:46:15 --- The thing is why does it work for some and not for others? Is it AMD? Or a non-english OS?
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #21 from Pablo Marchant pamarca@gmail.com 2009-07-17 21:47:48 --- Just tried this on a PC with an Intel proccessor. The error is exactly the same.
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #22 from Pablo Marchant pamarca@gmail.com 2009-07-17 22:59:41 --- Problem still persists in 1.1.26 however, there is a slight difference in the terminal output. It adds another line after the icall error, so now it looks like this:
* Assertion at ....\mono\mono\metadata\icall.c:5454, condition `err' not met err:ntdll:RtlpWaitForCriticalSection section 0x110058 "heap.c: main process heap section" wait timed out in thread 0018, blocked by 0009, retrying (60 sec)
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #23 from Pablo Marchant pamarca@gmail.com 2009-07-18 00:56:29 --- The error persists even after updating "The Sims 3" to the latest version, 1.2.7
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #24 from Jeff Zaroyko jeffz@jeffz.name 2009-07-18 02:33:40 --- Looking at that version of mono, although the line numbers don't match, the only assertions on `err' are two calls to SystemTimeToFileTime in a function named ves_icall_System_CurrentSystemTimeZone_GetTimeZoneData. So someone should trace the parameters and return value for SystemTimeToFileTime/RtlTimeFieldsToTime to check this.
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #25 from landeel cleberdemattoscasali-wine@yahoo.com.br 2009-07-18 12:17:37 --- ves_icall_System_CurrentSystemTimeZone_GetTimeZoneData... TimeZone, huh?
Well, I get this everytime I run wine:
fixme:ntdll:find_reg_tz_info Can't find matching timezone information in the registry for bias 180, std (d/m/y): 15/02/2009, dlt (d/m/y): 18/10/2009
Is it related?
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #26 from Pablo Marchant pamarca@gmail.com 2009-07-18 12:40:21 --- What about this bug??
http://bugs.winehq.org/show_bug.cgi?id=19011
It says that the timezone problem produces a crash on mono.
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #27 from Jeff Zaroyko jeffz@jeffz.name 2009-07-18 17:15:47 --- (In reply to comment #26)
What about this bug??
http://bugs.winehq.org/show_bug.cgi?id=19011
It says that the timezone problem produces a crash on mono.
Doesn't look related.
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #28 from Jeff Zaroyko jeffz@jeffz.name 2009-07-18 17:43:15 --- Created an attachment (id=22447) --> (http://bugs.winehq.org/attachment.cgi?id=22447) trace some time related functions
please apply this and reproduce the crash with the output attached as a file
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #29 from Pablo Marchant pamarca@gmail.com 2009-07-19 12:37:50 --- Created an attachment (id=22456) --> (http://bugs.winehq.org/attachment.cgi?id=22456) Terminal output with patched source
Here is the terminal output with the patch provided. Right before the error, it displays this:
fixme:ntdll:RtlTimeFieldsToTime Milliseconds: 0 Second: 0 Minute: 0 Hour: 0 Month: 3 Day: 92 Year: 2009 fixme:time:SystemTimeToFileTime RtlTimeFieldsToTime failed * Assertion at ....\mono\mono\metadata\icall.c:5454, condition `err' not met
Is that "Day: 92" a problem??
http://bugs.winehq.org/show_bug.cgi?id=18991
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #22456|application/octet-stream |text/plain mime type| |
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #30 from Pablo Marchant pamarca@gmail.com 2009-07-19 22:01:15 --- I just found a dirty hack that makes the game work. Its pretty dirty, so it will certainly affect other apps, however, with this, The Sims 3 doesnt crash and I can play it (no crashes yet).
Id submit a patch to this, but I dont know how to do them! So, ill just mention how I did it. In the source of wine 1.1.26, modify the file dlls/ntdll/time.c In line 220 of that file, add this line:
day=1;
So the final code around line 220 looks like this:
/* done */ day=1; Time->QuadPart = (((((LONGLONG) day * HOURSPERDAY +
Then compile, install, and it should work. From what I can see, this is a pretty dirty hack, since I override all the code used to specify the day in the date. However, it fixes the game (for now...). Hope this info can help someone create a decent fix.
http://bugs.winehq.org/show_bug.cgi?id=18991
Otto Rey otto_rey@yahoo.com.ar changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|1.1.23 |1.1.26
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #31 from Otto Rey otto_rey@yahoo.com.ar 2009-07-19 22:38:36 --- Still happen on 1.1.26. Now tested with AMD Phenom II 710 and NVIDIA 8200 IGP
http://bugs.winehq.org/show_bug.cgi?id=18991
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|1.1.26 |1.1.23
--- Comment #32 from Dmitry Timoshkov dmitry@codeweavers.com 2009-07-20 05:40:15 --- Please don't change the version field.
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #33 from landeel cleberdemattoscasali-wine@yahoo.com.br 2009-07-20 06:07:46 --- @Pablo Marchant : Can you post your modified ntdll.dll, so I can test it quicker?
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #34 from Ahmed Elmahdawy aa_mahdawy@hotmail.com 2009-07-20 06:10:13 --- Created an attachment (id=22470) --> (http://bugs.winehq.org/attachment.cgi?id=22470) Patched NTDLL.DLL. Workaround (Working - Verified)
Compiled ntdll.dll with patch.
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #35 from landeel cleberdemattoscasali-wine@yahoo.com.br 2009-07-20 06:59:05 --- No, it didn't work for me... Maybe other files are modified beside ntdll.dll? I'll do more tests later today.
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #36 from Ahmed Elmahdawy aa_mahdawy@hotmail.com 2009-07-20 07:04:04 --- You can try compiling with the day=1 fix. It worked here.
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #37 from Pablo Marchant pamarca@gmail.com 2009-07-20 11:06:22 --- Ahmed, your compiled ntdll didnt work for me with a fresh 1.1.26 wine. I had to use my patched version of wine, compiled with the day=1 fix.
However, it would be nice to provide the workaround in this way, so its only neccesary to change that instead of recompiling wine with a dirty hack.
http://bugs.winehq.org/show_bug.cgi?id=18991
Ahmed Elmahdawy aa_mahdawy@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #22330|Wine TS3 Town Crash Log |TS3.exe Terminal Output description|[Bug 18991] |
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #38 from landeel cleberdemattoscasali-wine@yahoo.com.br 2009-07-20 16:39:59 --- I have patched wine with the hack and now the game works.
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #39 from Otto Rey otto_rey@yahoo.com.ar 2009-07-20 16:55:58 --- A decent patch? Where 92 comes from? Wine developers: can you trace the code to see whats happen with the day value?
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #40 from landeel cleberdemattoscasali-wine@yahoo.com.br 2009-07-20 19:44:49 --- Created an attachment (id=22488) --> (http://bugs.winehq.org/attachment.cgi?id=22488) Hacked ntdll.dll.so
Make sure you backup your original ntdll.dll.so first, as this is an ugly hack. Extract ntdll.dll.so Place it on /usr/lib/wine/ (or /usr/lib32/wine/ if you're using x86_64). Works for me.
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #41 from Dmitry Timoshkov dmitry@codeweavers.com 2009-07-29 00:33:40 --- The following test case fails under XP:
static void test_RtlTimeFieldsToTime(void) { LARGE_INTEGER time; TIME_FIELDS tf; BOOL ret;
memset(&tf, 0, sizeof(tf)); tf.Month = 3; tf.Day = 92; tf.Year = 2009; ret = pRtlTimeFieldsToTime(&tf, &time); ok(ret, "RtlTimeFieldsToTime failed\n"); }
So it's necessary to figure out where '92' comes from.
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #42 from Otto Rey otto_rey@yahoo.com.ar 2009-08-03 22:44:15 --- Well, as far i can see, "some portion of code" is calling to dlls/kernel32/time.c, function SystemTimeToFileTime with invalid *syst struct members values. Next step: dump the stack trace in SystemTimeToFileTime and follow *syst parameter "build". How can i dump stack trace in c?
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #43 from Dmitry Timoshkov dmitry@codeweavers.com 2009-08-03 22:51:15 --- +relay,+ntdll,+time trace with Jeff's patch applied would be a good starting point.
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #44 from Otto Rey otto_rey@yahoo.com.ar 2009-08-09 19:15:13 --- I can't found relation between "mono source" (icall.c) and wine. Only dotnet20 (winetricks) looks related but i dont know what can i do with that. Is there a "hidden relation" between mono and wine (i have nothing related to mono installed on my system)? I don't see nothing related to mono in winetricks script when launch with dotnet20 parameter. I don't found nothing about mono in winetricks cache. I need help!!! :)
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #45 from Pablo Marchant pamarca@gmail.com 2009-08-09 19:23:26 --- Otto, your doubt was already answered in comment #19
I could supply more information here, but I dont know how to proceed. How could I obtain a trace to see where the day=92 erroneous setting was made??
Also, the error is still present in 1.1.27, If anyone knows how to proceed, plz tell and Ill do it right away.
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #46 from Otto Rey otto_rey@yahoo.com.ar 2009-08-09 23:36:48 --- Ok...
1- Wine win32 api implementation (SystemTimeToFileTime and RtlTimeFieldsToTime) validates something that M$ win32 api not
Or...
2- Maybe a wrong previously returned value from wine win32 to TS3.exe/Mono make the "later" crash
I mean... the same game, the same hardware, differents win32 implementations... one works the other sometimes...
I will try to debug wine...
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #47 from Otto Rey otto_rey@yahoo.com.ar 2009-08-10 00:08:43 --- Based on comment #24, i'll try to add some debug info in GetTimeZoneInformation and RtlQueryTimeZoneInformation. Maybe related to daylight saving?
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #48 from Dmitry Timoshkov dmitry@codeweavers.com 2009-08-10 01:09:25 --- See comment #41 and comment #43 for details.
http://bugs.winehq.org/show_bug.cgi?id=18991
Tom Lutraman@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Lutraman@gmail.com
--- Comment #49 from Tom Lutraman@gmail.com 2009-08-11 13:13:04 --- Can anyone help me how to do the day=1 fix. I've downloaded the wine source files using git, but my time.c file looks different from what you show here.
tnx
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #50 from Pablo Marchant pamarca@gmail.com 2009-08-11 13:25:09 --- Tom, its not neccesary to compile the sources, the hacked ntdll.dll.so is available, just check the instructions on comment #40 http://bugs.winehq.org/show_bug.cgi?id=18991#c40
Dmitry, I'm not very sure on how to modify the sources to get a trace, and your comment #43 is not very clear to me. Could you please explain it a bit more?
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #51 from Eduardo companheiro.vermelho@gmail.com 2009-08-11 17:04:37 --- Created an attachment (id=23008) --> (http://bugs.winehq.org/attachment.cgi?id=23008) Program to force the matching of a time zone
Another wilderness: I created a small test program (source code in bug 19011, http://bugs.winehq.org/show_bug.cgi?id=19011#c6 . Attached, the compiled version for easier testing) to "force" the matching of a time zone and maybe solve the problem. Not only it didn't solved the issue, but the timezone didn't match ONLY IN THE PREFIX WITH THE SIMS 3 INSTALLED. In all other wine prefixes (clean, old, with a lot of programs...), running this little program made the "fixme:ntdll:find_reg_tz_info Can't find matching timezone information..." disappear, as it should, except in the prefix with "The Sims 3" installed! Can someone test it and confirm this weirdness? Just run the program in the prefix and the fixme should disappear in all programs of that prefix. Backup your registry first!
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #52 from landeel cleberdemattoscasali-wine@yahoo.com.br 2009-08-11 17:19:45 --- I have tested it. I can confirm it fixes the "fixme:ntdll:find_reg_tz_info Can't find matching timezone information..blahblah...". But mono still crashes.
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #53 from Dmitry Timoshkov dmitry@codeweavers.com 2009-08-11 22:39:11 --- How to get a debugging log: http://wiki.winehq.org/FAQ#get_log http://wiki.winehq.org/FAQ#head-16da35b6327024d6ea576e3678488b16862d0f5e
How to apply a patch: http://wiki.winehq.org/FAQ#head-ce0f398b298dc31add49d49671b302b020e234bb
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #54 from Pablo Marchant pamarca@gmail.com 2009-08-11 23:21:55 --- Thanks Dmitry, your second link answered my question. I wont have access to my computer until past tomorrow, but Ill post the trace as soon as I do.
http://bugs.winehq.org/show_bug.cgi?id=18991
Eduardo companheiro.vermelho@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |companheiro.vermelho@gmail. | |com
--- Comment #55 from Eduardo companheiro.vermelho@gmail.com 2009-08-11 23:22:58 --- I have made a +relay log (300MB of stuff and I have only enabled logging short before trying to load a town) to try to understand where does the 92 comes from. I have searched for the address of the SYSTEMTIME variable passed to the SystemTimeToFileTime function and found nothing in the entire log. So I must conclude that or this variable was created a long time ago (before I started logging), or the variable was never set by wine and mono created a new SYSTEMTIME variable with a erroneous value. I believe the most probable is the second. It means that Windows does some weird stuff if it receives a invalid value on SYSTEMTIME and returns some value that doesn't make mono crash. Jeff, where exactly (source file, line...) did you found out that mono was calling SystemTimeToFileTime? I would like to take a look at this code... Also, I think it's time to fire up my Virtual Box and start testing some stuff on Windows. As soon as I get time to make some tests I will report (you guys make some tests too!)
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #56 from Tom Lutraman@gmail.com 2009-08-12 00:55:39 --- first, thank you for explaining to me about the ntdll, I now have it running. It's just worth mentioning that if you install the game using PlayOnLinux the directory to witch you need to replace the ntdll file is different that what shows on comment #40. It's seems obvious now, but it took me a while to figure out.
One more thing worth mentioning. I've noticed that anyone reported this problem had at least one more language beside English installed. I also have a second language. I'm not a developer, but it might be related, since most users don't seem to encounter that bug.
I'll be glad to help in anyway I can. just tell me how.
http://bugs.winehq.org/show_bug.cgi?id=18991
Ahmed Elmahdawy aa_mahdawy@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #22470|0 |1 is obsolete| |
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #57 from landeel cleberdemattoscasali-wine@yahoo.com.br 2009-08-12 15:25:25 --- I have noticed it too. I have created a new wine prefix with english language, and installed Sims 3 on it, but still the game crashes the same way.
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #58 from Otto Rey otto_rey@yahoo.com.ar 2009-08-16 13:57:56 --- Mono code (\mono\metadata\icall.c) call to GetTimeZoneInformation before call to SystemTimeToFileTime:
TIME_ZONE_INFORMATION tz_info; ... tz_id = GetTimeZoneInformation (&tz_info); ... err = SystemTimeToFileTime (&tz_info.StandardDate, &ft); ... err = SystemTimeToFileTime (&tz_info.DaylightDate, &ft); ...
Maybe that helps.
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #59 from Dmitry Timoshkov dmitry@codeweavers.com 2009-08-17 01:39:50 --- This is a bug in Mono, and they have removed all asserts due to reports from Windows users.
Here is the bug description:
In mono-2.4.2.3/mono/metadata/icall.c, ves_icall_System_CurrentSystemTimeZone_GetTimeZoneData() they call GetTimeZoneInformation(), and convert_to_absolute_date() assumes that the returned DST/STD time is always in the day-of-week format (wYear == 0). But that's not always the case. MSDN: "If the wYear member is not zero, the transition date is absolute; it will only occur one time. Otherwise, it is a relative date that occurs yearly."
In the mono-2.4.2.3 sources all asserts after convert_to_absolute_date() failuers are commented out.
The Mono bug has been fixed by the following commit:
2007-12-29 Miguel de Icaza miguel@novell.com
* icall.c (ves_icall_System_CurrentSystemTimeZone_GetTimeZoneData): Turn the assert into a negative result, the managed code already coped with that.
Some folks on Windows reported this error.
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #60 from Eduardo companheiro.vermelho@gmail.com 2009-08-17 19:49:42 --- (In reply to comment #58)
err = SystemTimeToFileTime (&tz_info.DaylightDate, &ft);
Oh! So THAT'S why the address didn't appear before in the log! Looks like I was mistaken...
Also, the mono bug report in comment #59 actually solves the mystery. But since it is not possible to update the bundled version of Mono and looks like windows does something when feed with a invalid date that prevents the crash, we still have a bug in wine to fix. Conformance tests are needed on some time-related functions of windows with weird input values.
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #61 from Dmitry Timoshkov dmitry@codeweavers.com 2009-08-18 00:48:36 --- (In reply to comment #60)
But since it is not possible to update the bundled version of Mono and looks like windows does something when feed with a invalid date that prevents the crash, we still have a bug in wine to fix. Conformance tests are needed on some time-related functions of windows with weird input values.
The test is in the Comment #41. According to it Windows does the same thing as Wine does. Notice, there is no crash, it's Mono who deliberately crashes itself due to its own bug. The bug older Mono versions are suffering from that bug only in some specific time zones (America/Sao_Paulo is one of them).
Actually this bug is a duplicate of the bug 19011. And that one should be marked as invalid.
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #62 from Eduardo companheiro.vermelho@gmail.com 2009-08-18 09:19:29 --- (In reply to comment #61)
(In reply to comment #60)
But since it is not possible to update the bundled version of Mono and looks like windows does something when feed with a invalid date that prevents the crash, we still have a bug in wine to fix. Conformance tests are needed on some time-related functions of windows with weird input values.
The test is in the Comment #41. According to it Windows does the same thing as Wine does. Notice, there is no crash, it's Mono who deliberately crashes itself due to its own bug. The bug older Mono versions are suffering from that bug only in some specific time zones (America/Sao_Paulo is one of them).
Actually this bug is a duplicate of the bug 19011. And that one should be marked as invalid.
But in Windows, with the same time zone, Mono doesn't crash!
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #63 from Dmitry Timoshkov dmitry@codeweavers.com 2009-08-18 10:09:09 --- (In reply to comment #62)
But in Windows, with the same time zone, Mono doesn't crash!
The explanation is in the Comment #10 of the bug 19011: Windows reports DST/STD dates in the day-of-week format (wYear == 0), and obviously reports it wrong. Choose one of the bugs you would prefer to have.
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #64 from Dmitry Timoshkov dmitry@codeweavers.com 2009-08-18 10:14:13 --- Apparently at least Ubuntu 7.04 has the same DST/STD dates as XP, so you have another option for running the game.
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #65 from landeel cleberdemattoscasali-wine@yahoo.com.br 2009-08-18 14:43:17 ---
The bug older Mono versions are suffering from that bug only in some specific time zones (America/Sao_Paulo is one of them).
Wow, I have changed my timezone from Sao Paulo to Bahia and the game simply works.
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #66 from Otto Rey otto_rey@yahoo.com.ar 2009-08-26 19:37:17 --- (In reply to comment #63)
(In reply to comment #62)
But in Windows, with the same time zone, Mono doesn't crash!
The explanation is in the Comment #10 of the bug 19011: Windows reports DST/STD dates in the day-of-week format (wYear == 0), and obviously reports it wrong. Choose one of the bugs you would prefer to have.
Ok, so... If I understand, Wine must reports DST/STD dates in day-of-week format with wrong values to be "more windows compatible". Is this the fix? Dmitry, can you do this?
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #67 from Dmitry Timoshkov dmitry@codeweavers.com 2009-08-26 23:54:01 --- (In reply to comment #66)
Ok, so... If I understand, Wine must reports DST/STD dates in day-of-week format with wrong values to be "more windows compatible". Is this the fix?
No, Wine shouldn't do that since Windows doesn't do that either. Wine behaviour is perfectly correct. It's a bug in older Mono versions, and Mono developers have fixed it because the bug caused problems for Windows users.
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #68 from Otto Rey otto_rey@yahoo.com.ar 2009-08-28 19:51:12 --- (In reply to comment #67)
(In reply to comment #66)
Ok, so... If I understand, Wine must reports DST/STD dates in day-of-week format with wrong values to be "more windows compatible". Is this the fix?
No, Wine shouldn't do that since Windows doesn't do that either. Wine behaviour is perfectly correct. It's a bug in older Mono versions, and Mono developers have fixed it because the bug caused problems for Windows users.
Ok, but... again: why the same game (with the same mono) works under Windows with the same timezone that Wine/Linux (in my case, America/Buenos Aires)?
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #69 from Dmitry Timoshkov dmitry@codeweavers.com 2009-08-29 01:10:07 --- (In reply to comment #68)
Ok, but... again: why the same game (with the same mono) works under Windows with the same timezone that Wine/Linux (in my case, America/Buenos Aires)?
Because Windows and Linux report different time zone information. Again, this is a Mono bug, and it has been confirmed and fixed by Mono developers.
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #70 from Mark hughes markh789@gmail.com 2009-08-29 08:42:49 --- (In reply to comment #69)
(In reply to comment #68)
Ok, but... again: why the same game (with the same mono) works under Windows with the same timezone that Wine/Linux (in my case, America/Buenos Aires)?
Because Windows and Linux report different time zone information. Again, this is a Mono bug, and it has been confirmed and fixed by Mono developers.
If its a Mono bug then why is this bug report still open?
Should this be closed/invalid?
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #71 from Jo Shields directhex@apebox.org 2009-08-29 09:15:43 ---
If its a Mono bug then why is this bug report still open?
Should this be closed/invalid?
It's not "a mono bug", It's a bug in the embedded scripting engine in Sims 3, which just happens to bea very old version of Mono. Your proposed fix is "mail EA and ask them to apply a mono patch"? Fine, do that. Meanwhile, Wine fails to behave like Windows in some countries, making it useless for this app.
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #71 from Jo Shields directhex@apebox.org 2009-08-29 09:15:43 ---
If its a Mono bug then why is this bug report still open?
Should this be closed/invalid?
It's not "a mono bug", It's a bug in the embedded scripting engine in Sims 3, which just happens to bea very old version of Mono. Your proposed fix is "mail EA and ask them to apply a mono patch"? Fine, do that. Meanwhile, Wine fails to behave like Windows in some countries, making it useless for this app.
--- Comment #72 from Jo Shields directhex@apebox.org 2009-08-29 09:16:28 ---
If its a Mono bug then why is this bug report still open?
Should this be closed/invalid?
It's not "a mono bug", It's a bug in the embedded scripting engine in Sims 3, which just happens to bea very old version of Mono. Your proposed fix is "mail EA and ask them to apply a mono patch"? Fine, do that. Meanwhile, Wine fails to behave like Windows in some countries, making it useless for this app.
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #73 from Pablo Marchant pamarca@gmail.com 2009-08-29 17:27:26 --- Is there a way to specify a timezone for use in a specific wineprefix?? Since the the timezone doesn't seem to have any impact at all in the game, guess this would be the most simple workaround...
http://bugs.winehq.org/show_bug.cgi?id=18991
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |el.il@doom.co.il
--- Comment #74 from Dmitry Timoshkov dmitry@codeweavers.com 2009-08-29 23:46:24 --- *** Bug 19011 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=18991
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |el.il@doom.co.il Status|NEW |RESOLVED Resolution| |INVALID
--- Comment #74 from Dmitry Timoshkov dmitry@codeweavers.com 2009-08-29 23:46:24 --- *** Bug 19011 has been marked as a duplicate of this bug. ***
--- Comment #75 from Dmitry Timoshkov dmitry@codeweavers.com 2009-08-29 23:47:40 --- Invalid. Old Mono bug.
http://bugs.winehq.org/show_bug.cgi?id=18991
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID Status|RESOLVED |CLOSED
--- Comment #75 from Dmitry Timoshkov dmitry@codeweavers.com 2009-08-29 23:47:40 --- Invalid. Old Mono bug.
--- Comment #76 from Dmitry Timoshkov dmitry@codeweavers.com 2009-08-29 23:48:04 --- Closing invalid.
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #77 from Dmitry Timoshkov dmitry@codeweavers.com 2009-08-29 23:54:55 --- (In reply to comment #73)
Is there a way to specify a timezone for use in a specific wineprefix??
WINEPREFIX=~/.foo TZ=bar wine notepad.exe
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #78 from Pablo Marchant pamarca@gmail.com 2009-08-30 00:13:38 --- Well so, the bug can be worked around just by running the sims like:
env WINEPREFIX="/home/pablo/.wine-sims" TZ="America/Bahia" wine "C:\Archivos de programa\Electronic Arts\The Sims 3\Game\Bin\TS3.exe"
Where, of course, you need to replace WINEPREFIX with the prefix where the sims 3 is installed, and "Archivos de programa" should be replaced with whatever it corresponds in your language ("Program files" in english I believe...)
I just tested this, and it works right. No need to modify the system timezone, or to use a "patched" ntdll
http://bugs.winehq.org/show_bug.cgi?id=18991
Benjamin Hodgetts ben@xnode.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ben@xnode.org
--- Comment #79 from Benjamin Hodgetts ben@xnode.org 2010-03-14 17:27:30 --- (In reply to comment #75)
Invalid. Old Mono bug.
Looking for clarification here:
Mono isn't installed on the Wine users machine so it can't be fixed by the user by simply updating Mono, it's embedded into the Windows app itself. The application works on Windows "as is" so surely it should work on Wine?
Just not entirely sure how/why this was marked as a Mono bug. The game works on this machine on Windows, if it's a Mono bug and Wine is doing exactly as Windows would then it should also work through Wine.
Also for the record:
TZ="America/Bahia" wine TS3.exe
Doesn't work for me, it still crashes in the same spot during the town load process so that workaround doesn't work (at least not anymore).
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #80 from Jo Shields directhex@apebox.org 2010-03-14 18:25:54 --- (In reply to comment #79)
Just not entirely sure how/why this was marked as a Mono bug. The game works on this machine on Windows, if it's a Mono bug and Wine is doing exactly as Windows would then it should also work through Wine.
Indeed. Replies 19 and 71 were ignored. The fix appears to be "make TS3 not be TS3" or "Obtain TS3 source, patch it" or some other impossible scenario.
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #81 from Vitaliy Margolen vitaliy@kievinfo.com 2010-03-14 23:14:59 --- (In reply to comment #80)
(In reply to comment #79)
Just not entirely sure how/why this was marked as a Mono bug. The game works on this machine on Windows, if it's a Mono bug and Wine is doing exactly as Windows would then it should also work through Wine.
Indeed. Replies 19 and 71 were ignored. The fix appears to be "make TS3 not be TS3" or "Obtain TS3 source, patch it" or some other impossible scenario.
Here we go again. Guys _READ_ the entire bug before making any assumptions. Especially comment 69.
This is bug in old Mono version. The only reason it doesn't trigger for you on Windows XP is because XP reports invalid DST/STD dates for your time zone. If you try to run this program on newer Windows version - it will fail in the same exact way as on Wine.
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #82 from Benjamin Hodgetts ben@xnode.org 2010-03-15 18:17:48 --- (In reply to comment #81)
This is bug in old Mono version. The only reason it doesn't trigger for you on Windows XP is because XP reports invalid DST/STD dates for your time zone. If you try to run this program on newer Windows version - it will fail in the same exact way as on Wine.
I read every post on this bug.
That's fair enough, but then surely if Wine is set to Windows XP compatibility mode then it should report dates in exactly the same way as XP does, should it not?
I don't think people are going to be happy that a bug is going to be closed without a fix so this game will never work, as "It's a mono bug" doesn't really solve the issue in any way shape or form. It works on XP, so if I set Wine to XP then it should work because it should be mimicking XP's behaviour.
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #83 from Vitaliy Margolen vitaliy@kievinfo.com 2010-03-15 22:04:10 --- (In reply to comment #82) You have an easy, simple and guaranteed to work workaround. Which doesn't break anything. Of course you are welcome to report this bug to makers of Sims for them to fix their game.
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #84 from Dmitry Timoshkov dmitry@codeweavers.com 2010-03-15 23:40:41 --- (In reply to comment #82)
That's fair enough, but then surely if Wine is set to Windows XP compatibility mode then it should report dates in exactly the same way as XP does, should it not?
No. Wine provides time zone information based on what an underlying OS reports to Wine.
http://bugs.winehq.org/show_bug.cgi?id=18991
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #85 from joaopa jeremielapuree@yahoo.fr 2010-03-16 05:47:38 ---
No. Wine provides time zone information based on what an underlying OS reports
to Wine.
Thats the problem. Wine should provide the same time zone information reported by windows, not the one reported by the underlying OS, right?
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #86 from Jeff Zaroyko jeffz@jeffz.name 2010-03-16 06:16:28 --- (In reply to comment #83)
(In reply to comment #82) You have an easy, simple and guaranteed to work workaround. Which doesn't break anything. Of course you are welcome to report this bug to makers of Sims for them to fix their game.
I've created an unofficial patch for Sims 3 based on a nocd patch, which fixes the bug in mono by modifying the executable. I don't have a copy of the game to test, so email me privately if you'd like to test it.
Fwiw, I don't think there is anything to fix in Wine. This problem has surfaced on Windows and was reported by Windows users to the Mono project.
http://bugs.winehq.org/show_bug.cgi?id=18991
--- Comment #87 from Dmitry Timoshkov dmitry@codeweavers.com 2010-03-16 06:28:41 --- (In reply to comment #85)
No. Wine provides time zone information based on what an underlying OS reports
to Wine.
Thats the problem. Wine should provide the same time zone information reported by windows, not the one reported by the underlying OS, right?
No. How would you explain say to Outlook user why the appointment time in his calendar doesn't match actual time she sees in the OS clock?
-
wine-bugs＠winehq.org