http://bugs.winehq.com/show_bug.cgi?id=720
maxx2(a)veneto.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Platform| |All
Resolution| |FIXED
------- Additional Comments From maxx2(a)veneto.com 2002-06-21 19:59 -------
Well, just tested the patch from P. Christeas and it works good !
The test has been done in Autocad 14, as usual, and the problem
is completely solved.
I guess this patch can go to cvs....
Regards
Max
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://bugs.winehq.com/show_bug.cgi?id=720>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://bugs.winehq.com/show_bug.cgi?id=816
------- Additional Comments From puoti(a)inwind.it 2002-06-21 19:10 -------
Created an attachment (id=182)
Hare is the full output of bug_report.pl
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://bugs.winehq.com/show_bug.cgi?id=816>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://bugs.winehq.com/show_bug.cgi?id=815
medbi01(a)accpac.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
------- Additional Comments From medbi01(a)accpac.com 2002-06-21 17:36 -------
Confirmed fixed (at least for the case of ACCPAC)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://bugs.winehq.com/show_bug.cgi?id=815>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://bugs.winehq.com/show_bug.cgi?id=815
------- Additional Comments From julliard(a)winehq.com 2002-06-21 16:53 -------
Should be fixed now.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://bugs.winehq.com/show_bug.cgi?id=815>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://bugs.winehq.com/show_bug.cgi?id=815
------- Additional Comments From andi(a)rhlx01.fht-esslingen.de 2002-06-21 16:31 -------
Argh, argh, argh.
Major confusion.
It seems the parameter count of __getmainargs/__GetMainArgs is everything but
obvious.
E.g. our crtdll has *4* parameters, whereas msvcrt has *5* !
Some Usenet postings even talk of 3 parameters !
Our crtdll calls into the 5 param __getmainargs, so that one *does* conversion.
Wanna bet msvcrt20 also uses 4 params only !?!?
That'd mean we'd have to write a msvcrt20 wrapper function just like for our crtdll.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://bugs.winehq.com/show_bug.cgi?id=815>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://bugs.winehq.com/show_bug.cgi?id=815
andi(a)rhlx01.fht-esslingen.de changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
------- Additional Comments From andi(a)rhlx01.fht-esslingen.de 2002-06-21 16:22 -------
ooook, now I see what the problem is...
(well, not quite, but much further)
Our builtin msvcrt20 has a __getmainargs *forward* entry, which thus calls
into native msvcrt __getmainargs.
For some reason the program seems to call our msvcrt20 __getmainargs with
new_mode set to NULL, which crashes native msvcrt, as it assumes that new_mode
is *never* NULL.
Can you try to find out why the program calls __getmainargs with new_mode set to
NULL ?
We need to know whether msvcrt20 __getmainargs can indeed be legally called with
a NULL new_mode.
If so, then we'd have to get rid of the forward to msvcrt __getmainargs, as
native msvcrt obviously has a problem with a NULL parameter here.
(IOW: we'd have to actually implement a msvcrt20 __getmainargs function that
calls into msvcrt __getmainargs, with a NULL new_mode check added)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://bugs.winehq.com/show_bug.cgi?id=815>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://bugs.winehq.com/show_bug.cgi?id=815
------- Additional Comments From medbi01(a)accpac.com 2002-06-21 16:13 -------
Sorry; I wasn't clear in my description. It isn't the argv[4]; it is the thing
that in the Wine copy is labelled as int *new_mode (See
dlls/msvcrt/data.c:__getmainargs). According to my local disassembly following
the stack dump the pointer is dereferenced without testing for null in the
native version.
The problem disappears as soon as the native msvcrt20 is used.
The full +relay trace is 50MB but that includes the parent program. The
offending process alone is only 2M. However I note that the Wine msvcrt20 is
rather empty; I'm a little surprised that there were no stub warnings.
Bill
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://bugs.winehq.com/show_bug.cgi?id=815>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://bugs.winehq.com/show_bug.cgi?id=815
------- Additional Comments From andi(a)rhlx01.fht-esslingen.de 2002-06-21 16:01 -------
Hmm, sounds like there might be an argc vs. argv[] incompatibility here...
Could you run --debugmsg +relay,+snoop
to check whether our msvcrt20 somehow somewhere returns one argument count
too many and thus the program dereferences the last non-existing (NULL) argument ?
Thanks !
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://bugs.winehq.com/show_bug.cgi?id=815>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://bugs.winehq.com/show_bug.cgi?id=815
Summary: msvcrt20 and msvcrt incompatibility
Product: Wine
Version: CVS
Platform: Other
OS/Version: other
Status: NEW
Severity: normal
Priority: P2
Component: wine-misc
AssignedTo: wine-bugs(a)winehq.com
ReportedBy: medbi01(a)accpac.com
This was detected working with Computer Associates Realizer with ACCPAC 4.2A
(Linux version)
When the builtin msvcrt20 is used with the native msvcrt.dll (6.0.8797.0) the
result is that msvcrt.dll.__getmainargs dereferences a null pointer fifth
argument, a memory access violation.
(For information only)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://bugs.winehq.com/show_bug.cgi?id=815>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.