http://bugs.winehq.com/show_bug.cgi?id=1878
Summary: scanf with %i doesn't work
Product: Wine
Version: 20030813
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: wine-binary
AssignedTo: wine-bugs(a)winehq.com
ReportedBy: wine(a)alphawave.net
scanfing with %i produces incorrect values and gives a return code of 0, the
following simple example show clearly illustrates the problem and shows that %d
is OK.
int main(int argc, char *argv[])
{
int i, n;
argc--;
argv++;
if (argc == 0) return 0;
n = sscanf(argv[0], "%i", &i);
printf("%%i %s = %i %i\n", argv[0], i, n);
n = sscanf(argv[0], "%d", &i);
printf("%%d %s = %i %i\n", argv[0], i, n);
return 0;
}
compiled with gcc/mingw
$ gcc -dumpversion
3.2.1
$ gcc -dumpmachine
i586-mingw32msvc
$ wine ./test.exe 123
%i 123 = 1074824480 0
%d 123 = 123 1
Wine exited with a successful status
This test program works fine on a Windows PC
--
Configure bugmail: http://bugs.winehq.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.com/show_bug.cgi?id=1877
Summary: halflife crashes with recent CVS
Product: Wine
Version: CVS
Platform: Other
OS/Version: Linux
Status: UNCONFIRMED
Severity: critical
Priority: P1
Component: wine-binary
AssignedTo: wine-bugs(a)winehq.com
ReportedBy: turgut(a)egenet.com.tr
System: mandrake 9.1, kernel: 2.4.22
halflife/cs crashes at startup when invoked with
wine -- hl.exe -gl -gldrv Default -full -w 1024 -game cstrike -noipx -nojoy
-numericping -console -toconsole
giving these errors:
err:ntdll:RtlpWaitForCriticalSection section 0x4024a0a0 "loader.c:
loader_section" wait timed out in thread 000a, blocked by 0009, retrying (60 sec)
wine: Unhandled exception (thread 000a), starting debugger...
err:ntdll:RtlpWaitForCriticalSection section 0x4024a0a0 "loader.c:
loader_section" wait timed out in thread 000a, blocked by 0009, retrying (60 sec)
(same setup worked before the last CVS update)
--
Configure bugmail: http://bugs.winehq.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.com/show_bug.cgi?id=1590
marcus(a)jet.franken.de changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |FIXED
------- Additional Comments From marcus(a)jet.franken.de 2003-11-12 00:42 -------
patch was applied to current CVS.
--
Configure bugmail: http://bugs.winehq.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.com/show_bug.cgi?id=1842
rhubarbpie(a)mail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #431 is|0 |1
obsolete| |
------- Additional Comments From rhubarbpie(a)mail.com 2003-10-12 17:55 -------
Created an attachment (id=433)
--> (http://bugs.winehq.com/attachment.cgi?id=433&action=view)
Requested debugging text.
--
Configure bugmail: http://bugs.winehq.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.com/show_bug.cgi?id=1874
------- Additional Comments From toph(a)abi2ooo.org 2003-10-12 17:35 -------
I ran the program in winedbg (log attached). The important lines are:
First chance exception: page fault on read access to 0x00000000 in 32-bit code
(0x40227519)
0x40227519 (NTDLL.DLL.ZwWriteFile+0xd9 in NTDLL.DLL): movl 0x0(%edx),%eax
I also checked the interesting differences between the working WineX-version and
the current Wine:
grep WriteFile winex/dlls/ntdll/*
winex/dlls/ntdll/ntdll.spec:@ stub NtWriteFile
winex/dlls/ntdll/ntdll.spec:@ stub ZwWriteFile
winex/dlls/ntdll/ntdll.spec:@ stub NtWriteFileGather
root@z1709 work # grep WriteFile wine-20031118/dlls/ntdll/*
wine-20031118/dlls/ntdll/file.c: * NtWriteFile
[NTDLL.@]
wine-20031118/dlls/ntdll/file.c: * ZwWriteFile [NTDLL.@]
wine-20031118/dlls/ntdll/file.c:NTSTATUS WINAPI NtWriteFile(HANDLE hFile, HANDLE
hEvent,
wine-20031118/dlls/ntdll/ntdll.spec:@ stdcall NtWriteFile(long long ptr ptr ptr
ptr long ptr ptr)
wine-20031118/dlls/ntdll/ntdll.spec:@ stdcall ZwWriteFile(long long ptr ptr ptr
ptr long ptr ptr) NtWriteFile
wine-20031118/dlls/ntdll/ntdll.spec:@ stub NtWriteFileGather
Does that mean that ZwWriteFile is not implemented in the current WineX at all
and that's the reason why WineX works and Wine doesn't?
--
Configure bugmail: http://bugs.winehq.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.com/show_bug.cgi?id=1763
------- Additional Comments From saulius.krasuckas(a)elst.vtu.lt 2003-10-12 06:37 -------
which version of ACAD are you trying to set up?
--
Configure bugmail: http://bugs.winehq.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.com/show_bug.cgi?id=1667
------- Additional Comments From Andrew.Talbot(a)talbotville.com 2003-10-12 04:31 -------
Mike,
OK, here are some results that spoil the party! Because I didn't want to overdo
the detail earlier, I deliberately omitted to mention that the Programmable
Interval Timer chip is fed from a crystal which oscillates at 3.579545 MHz,
(which just happens to be the chroma frequency for NTSC-N). Divide this by
three and you get 1.193182 MHz. Now, it was rumoured that some PCs use the 3x
clock straight, but I was sceptical - big mistake!
I have just tested five PCs from three different UK manufacturers, ranging from
a P2/400MHz to a P4/2.4GHz, most with Windows XP Professional, one with XP Home
Edition and, guess what, yep, they *all* show a QPF of 3579545!
I think it is true to say that Microsoft do not state what frequency one is
going to get when one uses the High-Performance Counter. So, I am rapidly being
drawn to the conclusion that we should forget about the RDTSC instruction
completely and just concentrate on getting whatever the PIT chip provides. I
gather this 82C54 chip takes the 3.58-MHz signal (as used by XP) and produces a
divided-by-three output (1.19 MHz, as used by Win98) and a
divided-by-a-further-65536 (18.2 Hz) output.
-- Andy.
--
Configure bugmail: http://bugs.winehq.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.com/show_bug.cgi?id=1876
Summary: Selfloading Exe causes " ... Win16Mutex" wait timed
Product: Wine
Version: CVS
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: wine-loader
AssignedTo: wine-bugs(a)winehq.com
ReportedBy: bon(a)elektron.ikp.physik.tu-darmstadt.de
http://www.elektronikladen.de/programmer/galep3/1175de.exe and
http://www.elektronikladen.de/programmer/galep3/1175ntde.exe are selfloading exes.
They cause wine to hang
err:ntdll:RtlpWaitForCriticalSection section 0x405b5b00 "syslevel.c: Win16Mutex"
wait timed out in thread 0009, blocked by 000b, retrying (60 sec)
I don't get any usefull debug or backtrace output
Following Mike Hearns advice on wine-devel
Mike Hearn Oct 15 19/672 "Re: Deadlock?"
I get
>walk process
pid threads parent executable
00000008 3 00000000 'H:\tmp\cae\1175de.exe'
Why don't I see thread 0x9 and 0xb?
>attach 0x8
takes a long time, with probably one dll loaded by winedbg with every 60 sec
timeout. The last message is
No debug information in 32bit DLL 'H:\tmp\cae\1175de.exe' (0x405f0000)
then nothing happens any more.
Running with
user.reg:"BreakOnAttach"=dword:00000001
Gives the same behaviour.
Starting the program in winedbg gives:
=>0 0x40224cc2 (RtlpWaitForCriticalSection+0xa2(crit=0x405b5b00)
[critsection.c:54] in NTDLL.DLL) (ebp=4070fcd4
)
1 0x40224f29 (RtlEnterCriticalSection+0x49(crit=0x405b5b00)
[critsection.c:1526] in NTDLL.DLL) (ebp=4070fce8)
2 0x4053493a (_EnterSysLevel+0x9a(lock=0x405b5b00) [syslevel.c:111] in
KERNEL32.DLL) (ebp=4070fd00)
3 0x40534d18 (RestoreThunkLock+0x28(mutex_count=0x1) [syslevel.c:228] in
KERNEL32.DLL) (ebp=4070fd18)
4 0x40536903 (OldYield16+0x23 [task.c:739] in KERNEL32.DLL) (ebp=4070fd2c)
5 0x40536955 (DirectedYield16+0x15(hTask=0x11df) [task.c:758] in KERNEL32.DLL)
(ebp=4070fd38)
6 0x4051c656 (NE_CreateThread+0x66(pModule=0x403e16c8, cmdShow=0x1,
cmdline=0x403df8e8) [ne_module.c:1324] in
KERNEL32.DLL) (ebp=4070fd58)
7 0x4051c7d0 (LoadModule16+0x110(name=0xbffff421, paramBlock=0x4070fefc)
[ne_module.c:1394] in KERNEL32.DLL)
(ebp=4070fd78)
8 0x40604416 (main+0x126(argc=0x4, argv=0xbffff218) [winevdm.c:218] in
winevdm.exe) (ebp=4070ff18)
9 0x40604039 (__wine_exe_main+0x39 [winevdm.exe.spec.c:123] in winevdm.exe)
(ebp=4070ff2c)
10 0x40521fcd (start_process+0xcd(arg=0x0) [process.c:750] in KERNEL32.DLL)
(ebp=4070fff4)
11 0x4001e3ed (wine_switch_to_stack+0x11 in libwine.so.1) (ebp=00000000)
55 if (!ret)
Wine-dbg>walk process
pid threads parent executable
0000000c 2 0000000a 'C:\NT4SP5G\SYSTEM32\wineconsole.exe'
>0000000a 3 00000008 'winevdm.exe'
--
Configure bugmail: http://bugs.winehq.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.com/show_bug.cgi?id=1875
Summary: CoCreateGuid under wine generates rather weak guid's
Product: Wine
Version: unspecified
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-binary
AssignedTo: wine-bugs(a)winehq.com
ReportedBy: luolin(a)dreamwork.cn
OS: redhat linux 9.0
wine: 20031118 rpm for rh9 (i386 & i686)
the following code is a bare stream test app compiled under microsoft 2000 sp4
visual studio .net 2003. it generates quite pleasing guid's under windows, but
when run the compiled binary directly under wine in my linux box, the generated
guid's are quite weak - guid.Data1 (32 bits) is a pseudo random number, and the
rest parts guid.Data2, guid.Data3, guid.Data4 are all the same for all the
guid's generated.
============================
#include <tchar.h>
#include <objbase.h>
#include <windows.h>
#include <iomanip>
#include <iostream>
int _tmain(int argc, _TCHAR* argv[])
{
for (int i = 0; i < 1000; ++i) {
GUID guid;
CoCreateGuid(&guid);
std::cout << std::hex << std::setw(8) << std::setfill('0') <<
guid.Data1 << ':';
std::cout << std::hex << std::setw(4) << std::setfill('0') <<
guid.Data2 << ':';
std::cout << std::hex << std::setw(4) << std::setfill('0') <<
guid.Data3 << ':';
UINT64 dnid;
memcpy(&dnid, guid.Data4, 8);
std::cout << std::hex << std::setw(16) << std::setfill('0') << dnid <<
std::endl;
}
return 0;
}
--
Configure bugmail: http://bugs.winehq.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.com/show_bug.cgi?id=1395
Steven_Ed4153(a)yahoo.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
------- Additional Comments From Steven_Ed4153(a)yahoo.com 2003-09-12 20:44 -------
the Heap*Alloc and ReAlloc Cleanup fixed this.
--
Configure bugmail: http://bugs.winehq.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.com/show_bug.cgi?id=530
Bug 530 depends on bug 528, which changed state.
Bug 528 Summary: Running C regression tests on Windows with Cygwin/MinGW
http://bugs.winehq.com/show_bug.cgi?id=528
What |Old Value |New Value
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
--
Configure bugmail: http://bugs.winehq.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.com/show_bug.cgi?id=1777
marcus(a)jet.franken.de changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |FIXED
------- Additional Comments From marcus(a)jet.franken.de 2003-09-12 17:36 -------
fixed in current release.
--
Configure bugmail: http://bugs.winehq.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.com/show_bug.cgi?id=1813
------- Additional Comments From marcus(a)jet.franken.de 2003-09-12 17:32 -------
can you give more?
save the output to a file, then look for the string "Could not load the
dll ..." string inside and quote the 50 lines before the first occurenence
of the string
--
Configure bugmail: http://bugs.winehq.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.com/show_bug.cgi?id=1873
marcus(a)jet.franken.de changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |CLOSED
------- Additional Comments From marcus(a)jet.franken.de 2003-09-12 17:29 -------
on request
--
Configure bugmail: http://bugs.winehq.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.com/show_bug.cgi?id=1873
marcus(a)jet.franken.de changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |INVALID
------- Additional Comments From marcus(a)jet.franken.de 2003-09-12 17:29 -------
on request.
--
Configure bugmail: http://bugs.winehq.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.com/show_bug.cgi?id=1582
------- Additional Comments From marcus(a)jet.franken.de 2003-09-12 16:31 -------
the fixme should be gone, the crash might not be.
please try with a new wine fversion
--
Configure bugmail: http://bugs.winehq.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.com/show_bug.cgi?id=737
marcus(a)jet.franken.de changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |FIXED
------- Additional Comments From marcus(a)jet.franken.de 2003-09-12 16:11 -------
last bugreport 1.5 years ago, considering fixed. if not, please reopen.
--
Configure bugmail: http://bugs.winehq.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.com/show_bug.cgi?id=1667
------- Additional Comments From Andrew.Talbot(a)talbotville.com 2003-09-12 16:09 -------
Mike,
Under Windows 98SE, on my P3/450, I ran your test2.exe program twice, with a
nominal twenty seconds between each run. Subtracting the two QPCs and dividing
by the timing period gave (472313655 - 448390410) / 20 = 1196162 ticks per
second. QPF was reported as 1193180: remarkably close. QPC, of course,
represents the number of clock ticks since switch-on. Programs can measure time
intervals by dividing differences in QPC by QPF, (i.e. tick-count-difference
divided by ticks-per-second = seconds elapsed) so the scalings have to be
consistent.
On my 'unscaled' version of Wine (SUSE 9.0), I also made two runs, this time
roughly thirty seconds apart, and got (191677227390 - 178935563205) / 30 =
424722139.5 counts per second from the two QPCs, with QPF given as 451054000.
Not bad for a crude, manual test.
It seems that versions of Windows <= Win98SE may have used the Programmable
Interrupt Timer (8254) chip, with its 1.19 Mhz clock (even on PCs with
RDTSC-capable processors). However, I suspect that other versions of Windows
(i.e. the more 'corporate' varieties: NT, Win2k, XP) might actually use the
RDTSC instruction, if available, thus providing the nanosecond-order resolution
of which the CPU clocks of modern computers are capable. So, perhaps the clock
that Wine uses for the High-Performance Timer functions (CPU vs. PIT) should
depend not only on the availability of the RDTSC instruction, but also on which
version of Windows that Wine is set to emulate.
I shall seek to run your program on at least one Win XP Pro machine to see which
clock that uses and shall report back here.
-- Andy.
--
Configure bugmail: http://bugs.winehq.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.