http://bugs.winehq.org/show_bug.cgi?id=34147
Bug #: 34147 Summary: Borland ilink32 malfunctions in newer versions of wine Product: Wine Version: 1.4.1 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: cnliou9@fastmail.fm Classification: Unclassified
Created attachment 45424 --> http://bugs.winehq.org/attachment.cgi?id=45424 The log.
Borland ilink32 version 5.66 runs properly in wine v1.0.1 in Debian squeeze. It crashes in wine v1.4.1 in Debian wheezy.
Comments on the attached log:
File O:\prog.tds is not locked by any other programs including IDE. Deleting this file before running ilink32.exe does not fix the problem.
If I remember correctly, the following two messages did not occurred to wine v1.0.1:
Warning: Cannot release virtual memory at addr 00000000 for 67108864 bytes (errcode 87)
Error: Could not delete O:\prog.tds (project already open in IDE?)
http://bugs.winehq.org/show_bug.cgi?id=34147
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #45424|application/octet-stream |text/plain mime type| |
http://bugs.winehq.org/show_bug.cgi?id=34147
--- Comment #1 from Nikolay Sivov bunglehead@gmail.com 2013-07-27 06:57:38 CDT --- How is O: disk configured? Also please first try with 1.6 (or recent dev version which doesn't differ much from 1.6 yet).
http://bugs.winehq.org/show_bug.cgi?id=34147
--- Comment #2 from CN Liou cnliou9@fastmail.fm 2013-07-27 09:40:33 CDT --- (In reply to comment #1)
How is O: disk configured? Also please first try with 1.6 (or recent dev version which doesn't differ much from 1.6 yet).
cd $HOME ln -s .wine/drive_c c mkdir .wine/drive_c/o
O: is mapped to $HOME/c/o C: is mapped to $HOME/c
I have just compiled wine v1.6 from source. When ilink32 runs in wine v1.6, it gives me exactly the same log as it did in wine v1.4.1.
My current wine configuration is intact since the upgrade of wine from v1.0.1 to v1.4.1 and then to v1.6.
http://bugs.winehq.org/show_bug.cgi?id=34147
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
--- Comment #3 from Austin English austinenglish@gmail.com 2013-07-29 17:30:01 CDT --- Please run a regression test: http://wiki.winehq.org/RegressionTesting
http://bugs.winehq.org/show_bug.cgi?id=34147
Dave Gomboc dave_gomboc@acm.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dave_gomboc@acm.org
--- Comment #4 from Dave Gomboc dave_gomboc@acm.org --- I have reproduced the reported problem with a relatively current wine release (from Debian Jessie, self-advertised as 1.6.2), then again with the 1.2.1 release (compiled from the wine git, after using the patch posted at the bottom of http://forum.winehq.org/viewtopic.php?f=8&t=19959). Both the v5.64 and v5.66 versions of ilink fail with the attempt to release virtual memory at the null (0) address.
Is there a way I could tell wine to ignore attempts by a Windows application to free memory blocks that begin at address 0? (In such circumstances, I think it is highly probable that the memory in question has already been freed, and that the application developer followed up by assigning NULL or 0, then a second attempt to free memeory was made.)
I attempted to find a version of wine that works with (at least one of) these ilink versions in order to begin an automated bisect, but notwithstanding the above patching, I am encountering compilation errors on older Wine versions. For example, I get this error output with wine-1.1.0, after configuring with CC="gcc -m32" CFLAGS="-g -O0" ./configure --verbose --disable-tests --without-freetype, make depend, and make:
gcc -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wtype-limits -Wpointer-arith -g -O0 -o cond.tab.o cond.tab.c cond.tab.c: In function ‘cond_parse’: cond.tab.c:64:25: error: too few arguments to function ‘cond_lex’ #define yylex cond_lex ^ cond.tab.c:1329:16: note: in expansion of macro ‘yylex’ yychar = yylex (&yylval); ^ cond.y:66:12: note: declared here static int cond_lex( void *COND_lval, COND_input *info); ^ cond.y:137:46: error: ‘info’ undeclared (first use in this function) COND_input* cond = (COND_input*) info; ^ cond.y:137:46: note: each undeclared identifier is reported only once for each function it appears in cond.y: In function ‘MSI_EvaluateConditionW’: cond.y:744:11: error: too many arguments to function ‘cond_parse’ if ( !cond_parse( &cond ) ) ^ cond.tab.c:63:25: note: declared here #define yyparse cond_parse ^ cond.tab.c:1160:1: note: in expansion of macro ‘yyparse’ yyparse (void) ^ Makefile:232: recipe for target 'cond.tab.o' failed make[2]: *** [cond.tab.o] Error 1 make[2]: Leaving directory '/home/dgomboc/gits/wine/dlls/msi' Makefile:766: recipe for target 'msi' failed make[1]: *** [msi] Error 2 make[1]: Leaving directory '/home/dgomboc/gits/wine/dlls' Makefile:397: recipe for target 'dlls' failed make: *** [dlls] Error 2
With wine-1.0, following the same build procedure as above, I get the following error:
gcc -m32 -c -I. -I. -I../../include -I../../include -DINCLUDEDIR=""/usr/local/include/wine"" -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wtype-limits -Wpointer-arith -g -O0 -o writeres.o writeres.c bison -p parser_ -o parser.tab.c -d parser.y parser.y: warning: 5 shift/reduce conflicts [-Wconflicts-sr] bison -p parser_ -o parser.tab.c parser.y parser.y: warning: 5 shift/reduce conflicts [-Wconflicts-sr] gcc -m32 -c -I. -I. -I../../include -I../../include -DINCLUDEDIR=""/usr/local/include/wine"" -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wtype-limits -Wpointer-arith -g -O0 -o parser.tab.o parser.tab.c parser.y: In function ‘rsrcid_to_token’: parser.y:2990:15: error: ‘YYLEX’ undeclared (first use in this function) lookahead = YYLEX; ^ parser.y:2990:15: note: each undeclared identifier is reported only once for each function it appears in parser.y:2986:14: warning: variable ‘type’ set but not used [-Wunused-but-set-variable] const char *type = "?"; ^ Makefile:170: recipe for target 'parser.tab.o' failed make[2]: *** [parser.tab.o] Error 1 make[2]: Leaving directory '/home/dgomboc/gits/wine/tools/wrc' Makefile:381: recipe for target 'wrc' failed make[1]: *** [wrc] Error 2 make[1]: Leaving directory '/home/dgomboc/gits/wine/tools' Makefile:396: recipe for target 'tools' failed make: *** [tools] Error 2
With wine-0.9, I get breakage during the make depend step:
bison -d -t ./parser.y -o parser.tab.c ./parser.y:278.8-14: warning: symbol tSTRING redeclared [-Wother] %token tSTRING tIDENT tRAWDATA ^^^^^^^ ./parser.y:278.16-21: warning: symbol tIDENT redeclared [-Wother] %token tSTRING tIDENT tRAWDATA ^^^^^^ ./parser.y:278.23-30: warning: symbol tRAWDATA redeclared [-Wother] %token tSTRING tIDENT tRAWDATA ^^^^^^^^ ./parser.y: warning: 5 shift/reduce conflicts [-Wconflicts-sr] gcc -m32 -c -I. -I. -I../../include -I../../include -DINCLUDEDIR=""/usr/local/include/wine"" -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wdeclaration-after-statement -Wpointer-arith -g -O0 -o parser.tab.o parser.tab.c ./parser.y: In function ‘convert_ctlclass’: ./parser.y:2075:15: warning: comparison between ‘enum name_e’ and ‘enum str_e’ [-Wenum-compare] if(cls->type == str_unicode) ^ ./parser.y: In function ‘rsrcid_to_token’: ./parser.y:2922:14: warning: variable ‘type’ set but not used [-Wunused-but-set-variable] const char *type = "?"; ^ flex -Cf -d -8 ./parser.l gcc -m32 -c -I. -I. -I../../include -I../../include -DINCLUDEDIR=""/usr/local/include/wine"" -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wdeclaration-after-statement -Wpointer-arith -g -O0 -o lex.yy.o lex.yy.c lex.yy.c:7361:15: error: expected ‘;’, ‘,’ or ‘)’ before numeric constant #define yystr 1 ^ lex.yy.c:9233:48: note: in expansion of macro ‘yystr’ YY_BUFFER_STATE yy_scan_string (yyconst char * yystr ) ^ lex.yy.c:8745:17: warning: ‘yyunput’ defined but not used [-Wunused-function] static void yyunput (int c, register char * yy_bp ) ^ lex.yy.c:8795:16: warning: ‘input’ defined but not used [-Wunused-function] static int input (void) ^ lex.yy.c:9320:16: warning: ‘yy_top_state’ defined but not used [-Wunused-function] static int yy_top_state (void) ^ Makefile:150: recipe for target 'lex.yy.o' failed make[2]: *** [lex.yy.o] Error 1 make[2]: Leaving directory '/home/dgomboc/gits/wine/tools/wrc' Makefile:322: recipe for target 'wrc' failed make[1]: *** [wrc] Error 2 make[1]: Leaving directory '/home/dgomboc/gits/wine/tools' Makefile:342: recipe for target 'tools' failed make: *** [tools] Error 2
Are there additional patches that should be added to the pool of six? 3f98185fb8f88c181877e909ab1b6422fb9bca1e 8fcac3b2bb8ce4cdbcffc126df779bf1be168882 bda5a2ffb833b2824325bd9361b30dbaf5f78068 c14e322a92a24e704836c5c12207c694a30e805f f86c46f6403fe338a544ab134bdf563c5b0934ae ffbe1ca986bd299e1fc894440849914378adbf5
While I cannot sink a ton of time into figuring out my own workarounds for various compilation problems from scratch, if someone who has previously encountered these or similar can chime in with how to work around them, then I can work the git bisect and pin down the commit that introduced the breakage.
Alternatively, the second paragraph of this message might suggest a quicker way for someone knowledgeable with wine to track down the issue.
https://bugs.winehq.org/show_bug.cgi?id=34147
--- Comment #5 from Dave Gomboc dave_gomboc@acm.org --- I found that Wine can be cleanly compiled on many versions (though, granted, not every version) from 0.9.10 all the way to 1.7.24 and the current tip of master using Debian Lenny 5.0.10 within VirtualBox (4.3.14), using the configuration line CC="ccache gcc" CFLAGS="-g -O0" ./configure --verbose --disable-tests
Using this setup, I have been able to ascertain that ilink566.exe did indeed used to work, and no longer does. The bisection I performed isolated one regression point to be between 1.1.24 and 1.1.25: SHA c68594a worked, but SHA 0971259 failed.
Using the configuration line CC="ccache gcc" ./configure --verbose --disable-tests
on these two commits also resulted in c68594a working and 0971259 failing.
https://bugs.winehq.org/show_bug.cgi?id=34147
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |julliard@winehq.org Component|-unknown |ntdll Regression SHA1| |09712593c8496be5e952b731609 | |9f9eed5043203
--- Comment #6 from Austin English austinenglish@gmail.com --- Thanks, adding commit/author to CC.
https://bugs.winehq.org/show_bug.cgi?id=34147
--- Comment #7 from Dave Gomboc dave_gomboc@acm.org --- I just retested the problem against 1.7.34. The same failure occurs.
If any fixes are attempted, I can test them out.
https://bugs.winehq.org/show_bug.cgi?id=34147
super_man@post.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |super_man@post.com
--- Comment #8 from super_man@post.com --- Bug 23318 has the same regression id.
https://bugs.winehq.org/show_bug.cgi?id=34147
winetest@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest@luukku.com
--- Comment #9 from winetest@luukku.com --- (In reply to Dave Gomboc from comment #7)
I just retested the problem against 1.7.34. The same failure occurs.
If any fixes are attempted, I can test them out.
Could you retest wine 1.8, 1.9 or 2.0 series? The higher the number the better.
https://bugs.winehq.org/show_bug.cgi?id=34147
--- Comment #10 from CN Liou cnliou9@fastmail.fm --- The same error remains with version 2.0-rc3.
https://bugs.winehq.org/show_bug.cgi?id=34147
--- Comment #11 from Alexandre Julliard julliard@winehq.org --- If you can still reproduce, please attach a +relay,+virtual trace.
https://bugs.winehq.org/show_bug.cgi?id=34147
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #12 from joaopa jeremielapuree@yahoo.fr --- Does the bug still occur in current wine(3.21)?
https://bugs.winehq.org/show_bug.cgi?id=34147
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |ABANDONED Status|UNCONFIRMED |RESOLVED
--- Comment #13 from Gijs Vermeulen gijsvrm@gmail.com --- No reply for 3 years (Comment #11), no download available, marking ABANDONED.
https://bugs.winehq.org/show_bug.cgi?id=34147
--- Comment #14 from Austin English austinenglish@gmail.com --- Closing.
https://bugs.winehq.org/show_bug.cgi?id=34147
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #15 from Austin English austinenglish@gmail.com --- Closing.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla