http://bugs.winehq.org/show_bug.cgi?id=17232
Summary: Lohnabzug: consistently crashes on first run after install Product: Wine Version: 1.1.14 Platform: Other OS/Version: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: a.strich.b@web.de
Created an attachment (id=19206) --> (http://bugs.winehq.org/attachment.cgi?id=19206) console log of the crash on first run
When I try to start Lohnabzug (demo version), the app crashes on the first attempt after install. On further attempts, it starts (although it immediately crashes due to missing jet40; winetricks helps).
You can get the demo online, after you fill in the two mandatory fields of the form at http://www.dataline.de:80/sites/DEMO.html (Firma = Company name)
http://bugs.winehq.org/show_bug.cgi?id=17232
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |dotnet, download OS/Version|other |Linux
http://bugs.winehq.org/show_bug.cgi?id=17232
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net
--- Comment #1 from Anastasius Focht focht@gmx.net 2009-04-23 13:30:24 --- Hello,
the app needs .NET 2.0 Framework. Because you didn't install that prerequisite *before* the app installer you run into bug 10467
AGAIN: Don't let app installers do .NET 2.0 installation! Always check appdb .NET Framework entries for instructions how deal with .NET based apps!
Regards
http://bugs.winehq.org/show_bug.cgi?id=17232
--- Comment #2 from Andreas Hermann Braml a.strich.b@web.de 2009-04-23 14:16:02 --- On first run, the app never starts. It makes no difference if I install .NET via winetricks first or let it be installed by the app's installer. (tested on 1.1.19)
http://bugs.winehq.org/show_bug.cgi?id=17232
--- Comment #3 from Andreas Hermann Braml a.strich.b@web.de 2009-04-23 14:37:26 --- Created an attachment (id=20641) --> (http://bugs.winehq.org/attachment.cgi?id=20641) log of the failed first attempt with 1.1.19
This is the console output I get with wine 1.1.19; .NET was installed beforehand via winetricks
http://bugs.winehq.org/show_bug.cgi?id=17232
--- Comment #4 from Anastasius Focht focht@gmx.net 2009-04-23 15:24:10 --- Hello,
--- quote --- this is the console output I get with wine 1.1.19; .NET was installed beforehand via winetricks --- quote ---
Did you notice the difference in the backtraces you posted? Sorry, but you're still not paying attention to appdb!
First you posted backtraces from "start.exe" with a broken WINEPREFIX. Now you are posting backtrace from "democonfig.exe" with a broken WINEPREFIX.
Do you think this is funny?
Again: Please don't use tainted/broken WINEPREFIXes for installing/testing/reporting bugs!
I tested it myself. Clean WINEPREFIX and only 'winetricks -q dotnet20 jet40' Downloaded and installed the app. It starts and doesn't crash on the first attempt after install.
There is one show stopper crash because the app installs its own gecko engine which conflicts with Wine's one (pulled in by winetricks dotnet20). Though that can be manually fixed by removing nspr4.dll from system32.
Regards
http://bugs.winehq.org/show_bug.cgi?id=17232
--- Comment #5 from Andreas Hermann Braml a.strich.b@web.de 2009-04-23 15:57:43 --- So 'rm -rf .wine' is not enough anymore? Curious.
Yes, I see that the backtraces differ. (That's why I posted the second one in the first place). No, I don't run democonfig.exe one day and start.exe the other, depending on the constellation of the stars. I consistently run Start.exe from the Start directory of the application. Always.
And no, I'm not a complete moron.
Instead of imflammatory accusations, you could simply have asked if you needed more information as to what exactly I did to come across the bug. So here goes.
rm -rf .wine # standard procedure whenever I do anything Wine ./winetricks mdac28 jet40 dotnet20 wine setup-demo.exe cd .wine/drive_c/Programme/DATALINE\ Office/Start/ wine Start.exe
The problem with the nspr4.dll is a known issue (see appdb)
http://bugs.winehq.org/show_bug.cgi?id=17232
--- Comment #6 from Anastasius Focht focht@gmx.net 2009-04-23 16:30:39 --- Hello,
--- quote --- Instead of imflammatory accusations, you could simply have asked if you needed more information as to what exactly I did to come across the bug. So here goes.
rm -rf .wine # standard procedure whenever I do anything Wine ./winetricks mdac28 jet40 dotnet20 wine setup-demo.exe cd .wine/drive_c/Programme/DATALINE\ Office/Start/ wine Start.exe --- quote ---
It's standard practice to provide basic instructions in first place (read: required steps) how the app was installed so whoever investigates the bug can reproduce it without much loss of time. That means *all* required prerequisites and not only half of the information so one can do guesswork first.
Yes, I was a bit angry because you didn't provide the basic required information in the first place and were not being honest about your WINEPREFIX setup (yes the prefix was *broken* for sure).
Anyway: None of the crashes are reproducable with the steps here. The app works fine at least for (first and consecutive) startup and basic stuff. I even resetted my GIT head back to 1.1.19 to exactly match your version.
Regards
http://bugs.winehq.org/show_bug.cgi?id=17232
--- Comment #7 from Anastasius Focht focht@gmx.net 2009-04-23 17:23:00 --- Hello,
well at least the second backtrace (comment #3) looks like a corrupted/non-conformant truetype font which might be present in your filesystem.
Can you run the app with following command line until the crash:
--- snip --- WINEDEBUG=+tid,+seh,+loaddll,+font wine foo.exe >log.txt 2>&1 --- snip ---
and attach the log file here.
Regards
http://bugs.winehq.org/show_bug.cgi?id=17232
--- Comment #8 from Andreas Hermann Braml a.strich.b@web.de 2009-04-23 19:20:54 --- Created an attachment (id=20651) --> (http://bugs.winehq.org/attachment.cgi?id=20651) first run with WINEDEBUG=+tid,+seh,+loaddll,+font
console log of first run with WINEDEBUG=+tid,+seh,+loaddll,+font wine Start.exe 2>&1
http://bugs.winehq.org/show_bug.cgi?id=17232
--- Comment #9 from Anastasius Focht focht@gmx.net 2009-04-24 15:58:37 --- Hello,
additionally please run (whole command is one line):
--- snip --- WINEDEBUG=+tid,+seh,+relay wine start.exe >/tmp/relay.log 2>&1 ; grep -A 50 -B 4000 "AccessViolationException" /tmp/relay.log >crash.txt --- snip ---
and attach "crash.txt" to bug report. Thanks.
Regards
http://bugs.winehq.org/show_bug.cgi?id=17232
--- Comment #10 from Andreas Hermann Braml a.strich.b@web.de 2009-04-24 17:41:21 --- When I run the command from #9, on first run crash.txt is empty. Only on the second run I get output there.
Do you want me to post that or is it useless, as far as this bug is concerned?
http://bugs.winehq.org/show_bug.cgi?id=17232
--- Comment #11 from Anastasius Focht focht@gmx.net 2009-04-25 02:00:14 --- Hello,
--- quote --- When I run the command from #9, on first run crash.txt is empty. Only on the second run I get output there.
Do you want me to post that or is it useless, as far as this bug is concerned? --- quote ---
Well, if that command line doesn't work for you due to different crash/exception message or process doesn't exit (pipe), ctrl+c, you might try to split it up, e.g. first let it create the relay log:
--- snip --- WINEDEBUG=+tid,+seh,+relay wine start.exe >relay.log 2>&1 --- snip ---
and then filter out only the relevant parts:
--- snip --- grep -A 50 -B 4000 "AccessViolationException" relay.log >crash.txt --- snip ---
If the second step still leaves an empty file, there might be a different bug. Just keep trying (install+start) until you see parts of the CLR backtrace:
--- snip --- ... Unhandled Exception: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt. at System.Drawing.SafeNativeMethods.Gdip.GdipCreateFontFromLogfontW(HandleRef hdc, Object lf, IntPtr& font) at System.Drawing.Font.FromLogFont(Object lf, IntPtr hdc) at System.Drawing.Font.FromHfont(IntPtr hfont) at System.Drawing.SystemFonts.get_DefaultFont() at System.Windows.Forms.Control.get_Font() ... --- snip ---
If that relay.log isn't too large you attach it as plain text file. Otherwise compress it (bzip2) and attach it to this bug like you did with the other logs. Just make sure it contains the backtrace as shown above.
Regards
http://bugs.winehq.org/show_bug.cgi?id=17232
--- Comment #12 from Andreas Hermann Braml a.strich.b@web.de 2009-04-26 09:11:01 --- Created an attachment (id=20729) --> (http://bugs.winehq.org/attachment.cgi?id=20729) first run with WINEDEBUG=+tid,+seh,+relay on 1.1.20
output of
WINEDEBUG=+tid,+seh,+relay wine start.exe >/tmp/relay.log 2>&1 ; grep -A 50 -B 4000 "AccessViolationException" /tmp/relay.log >crash.txt
on 1.1.20
http://bugs.winehq.org/show_bug.cgi?id=17232
--- Comment #13 from Anastasius Focht focht@gmx.net 2009-04-26 09:40:59 --- Hello,
thanks. Unfortunately the log file is still too short to narrow it down (last 4000 lines before crash not enough). Can you compress the whole relay.log and attach it?
Regards
http://bugs.winehq.org/show_bug.cgi?id=17232
Andreas Hermann Braml a.strich.b@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #20729|0 |1 is obsolete| |
http://bugs.winehq.org/show_bug.cgi?id=17232
--- Comment #14 from Andreas Hermann Braml a.strich.b@web.de 2009-04-26 14:51:43 --- I uploaded the compressed relay.log to my web site here:
http://www.braml.org/relay.log.bz2
http://bugs.winehq.org/show_bug.cgi?id=17232
--- Comment #15 from Anastasius Focht focht@gmx.net 2009-04-26 15:31:07 --- Hello,
yes it's a bad font issue. Looks like you have a broken Samyak-Oriya truetype font.
--- snip --- /usr/share/fonts/truetype/ttf-oriya-fonts/samyak-oriya.ttf --- snip ---
Options:
1) rename/remove the following font manually (no idea if it's actually needed) 2) update to a newer font package version if your Linux distribution provides it 3) use 'winetricks fontfix' step.
1)+2) have the risk of additional broken fonts (like ukai) which also need to be fixed for .NET
That leaves option 3) as most viable ;-)
Although you used 'winetricks dotnet20' which should ideally have fixed your problem it seems you used an older version of 'winetricks' script. Please update to a newer version of 'winetricks' script (wget http://kegel.com/wine/winetricks) to make sure you get the Samyak-Oriya fontfix.
'winetricks fontfix' (or 'winetricks dotnet20' which includes 'fontfix' step) will not only install a working version of this font but also might fix other fonts known as broken (like the notorious "ukai"). Don't worry, your original (broken) ones from distribution will be left unchanged. The "good" fonts get installed into Wine/Windows font directory which has higher font search path precedence - so the good ones will be pulled in when found before defaulting to linux ones.
Please report back if it works for you. If you still encounter the same type of crash after applying 'winetricks fontfix' step, please provide another relay log.
Regards
http://bugs.winehq.org/show_bug.cgi?id=17232
--- Comment #16 from Andreas Hermann Braml a.strich.b@web.de 2009-04-27 10:26:20 --- I tried option 3) from #15, but it didn't work; the crash still occurs. The relay.log is at
http://www.braml.org/relay-anothertry.log.bz2
The winetricks I use is the latest one. As far as I understand what the wintricks script does, it seems that samyak-oriya doesn't get fixed by the 'fontfix' target, though, only uming and ukai do.
When I remove the ttf-oriya-fonts (option 1) in #15), the bug does not occur.
So it seems this is no Wine issue after all. But where to report this now? At winetricks, so that they can introduce another dirty hack? I guess so; the fact that fontfix is in there at all tells me that the real upstream for the fonts isn't very likely to fix this issue soon :(
http://bugs.winehq.org/show_bug.cgi?id=17232
--- Comment #17 from Anastasius Focht focht@gmx.net 2009-04-27 11:44:39 --- Hello,
ok I see it now, the fix for broken Samyak truetype font still lives only in trunk but not in official wintricks release from kegel.com
You might try a newer version from there:
--- snip --- svn export http://winezeug.googlecode.com/svn/trunk/winetricks --- snip ---
--- quote --- So it seems this is no Wine issue after all. But where to report this now? At winetricks, so that they can introduce another dirty hack? I guess so; the fact that fontfix is in there at all tells me that the real upstream for the fonts isn't very likely to fix this issue soon :( --- quote ---
Actually I don't know in detail if the problem is due to M$ way of interpreting truetype/opentype standards (compliancy) or real bugs with the font (header/tables/properties/glyph outlines). Fedora had significant fixes for this font package last year, I don't know about Ubuntu.
I suggest that you add a "HOWTO" section to the appdb entry you manage (http://appdb.winehq.org/objectManager.php?sClass=version&iId=15365) describing all the steps needed to get the app to run. Just something like: "Make sure you install app xxx in clean WINEPREFIX" "use winetricks 'aaa bbb ccc' to install required prerequisites" (and description where to get it) "run the installer" "<additional notes" (like the automatic/manual font fixes needed when encountering this problem) That way people overcome obstacles easier and guesswork is prevented.
People tend to look for "HOWTO" and/or "NOTES" when visiting appdb entry but not study test reports. You put the crucial info in the test report.
If you need examples have a look at the entries I manage (although a bit over-engineered to cover every possible user error) ;-)
You close this bug -> "INVALID" because the problem is not a Wine bug.
Regards
http://bugs.winehq.org/show_bug.cgi?id=17232
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |INVALID
--- Comment #18 from Austin English austinenglish@gmail.com 2009-04-27 11:49:44 --- Invalid, per Anastasius.
http://bugs.winehq.org/show_bug.cgi?id=17232
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #19 from Austin English austinenglish@gmail.com 2009-04-27 11:50:03 --- Closing.
http://bugs.winehq.org/show_bug.cgi?id=17232
--- Comment #20 from Andreas Hermann Braml andreas@braml.org 2009-04-27 14:12:33 --- Nevertheless: thank you Anastasius, were it only for the enlightenment on how to use appdb and bugzilla more considerately, i.e. avoid guesswork on developers'/triagers'/users' side!
-
wine-bugs＠winehq.org