June 2003 - Wine-Devel - list.winehq.org

Strange Crash in Direct X init
by Robert Lunnon June 23, 2003

June 23, 2003

I have a strange crash in thread creation with a program called little fighter II (Which is downloadable off the internet) LF2 Spawns a Thread in User_DirectDrawSurface_Construct (below) and when created the thread creation call crashes in a mutex_lock. Strange thing is the same thread creation calll in eudora3.2 succeeds although there the thread is created to service Asychronous Winsock calls. In the eudora case the Thread is created much later, after the window is up and dispalyed. Can anyone hazard a guess as to what is happening here ? I am at a loss to explain why the same call should succeed in one place and fall over in another See below for a partial debug session transcript of the code leading up to the segv fault the program will fall over during the call to _lwp_create. Bob... The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /export/home/local/bin/wine ./lf2 Setting Signal Handlers err:font:ReadFontDir Can't open directory "/usr2/robert/c/windows/Fonts" x11drv: Warning: $DISPLAY variable ignored, using ':0.0' specified in config file fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (dd5c9438)->(00010022,00000008) Breakpoint 1, SYSDEPS_SpawnThread (teb=0xdc043000) at ../../scheduler/sysdeps.c:204 204 fprintf(stderr,"Starting New Thread Via thr_create stack base = %lx size =%d\n",teb->stack_base, (char *)teb->stack_top - ( char *)teb->stack_base); (gdb) bt #0 SYSDEPS_SpawnThread (teb=0xdc043000) at ../../scheduler/sysdeps.c:204 #1 0xddb07fad in CreateThread (sa=0x0, stack=0, start=0xdcf0e50c <User_update_thread>, param=0xdd5c9bd0, flags=0, id=0x0) at ../../scheduler/thread.c:289 #2 0xdcf0de1b in User_DirectDrawSurface_Construct (This=0xdd5c9bd0, pDD=0xdd5c9438, pDDSD=0xdd522cbc) at dsurface/user.c:101 #3 0xdcf0decc in User_DirectDrawSurface_Create (pDD=0xdd5c9438, pDDSD=0xdd522cbc, ppSurf=0xdd522d84, pUnkOuter=0x0) at dsurface/user.c:140 #4 0xdcf02ae1 in HAL_DirectDraw_create_primary (This=0xdd5c9438, pDDSD=0xdd522cbc, ppSurf=0xdd522d84, pUnkOuter=0x0) at ddraw/hal.c:446 #5 0xdcf03bc2 in create_primary (This=0xdd5c9438, pDDSD=0xdd522dac, ppSurf=0xdd522d84, pUnkOuter=0x0) at ddraw/main.c:473 #6 0xdcf03f74 in Main_DirectDraw_CreateSurface (iface=0xdd5c9438, pDDSD=0xdd522dac, ppSurf=0xdd522d84, pUnkOuter=0x0) at ddraw/main.c:593 #7 0xdcf058cb in IDirectDrawImpl_CreateSurface (This=0xdd5c9444, pSDesc=0xdd522dac, ppSurface=0x44a854, pUnkOuter=0x0) at ddraw/thunks.c:207 #8 0x00401216 in ?? () #9 0xddb03aec in start_process () at ../../scheduler/process.c:455 #10 0xddb06f0e in call_on_thread_stack (func=0xddb03908) at ../../scheduler/sysdeps.c:124 (gdb) up #1 0xddb07fad in CreateThread (sa=0x0, stack=0, start=0xdcf0e50c <User_update_thread>, param=0xdd5c9bd0, flags=0, id=0x0) at ../../scheduler/thread.c:289 289 if (SYSDEPS_SpawnThread( teb ) == -1) (gdb) list 284 teb->entry_arg = param; 285 teb->startup = THREAD_Start; 286 teb->htask16 = GetCurrentTask(); 287 288 if (id) *id = tid; 289 if (SYSDEPS_SpawnThread( teb ) == -1) 290 { 291 CloseHandle( handle ); 292 close( request_pipe[1] ); 293 THREAD_FreeTEB( teb ); (gdb) print teb $1 = (TEB *) 0xdc043000 (gdb) print *teb $2 = {except = 0xffffffff, stack_top = 0xdc043000, stack_low = 0xdbe20000, htask16 = 279, stack_sel = 0, fiber = 0x0, user_ptr = 0, self = 0xdc043000, tibflags = 1, mutex_count = 0, pid = 0, tid = 10, queue = 0, pad1 = 0, tls_ptr = 0x0, Peb = 0xddb78d40, flags = 0, exit_code = 259, teb_sel = 423, emu_sel = 0, unknown1 = 0, unknown2 = 0, startup = 0xddb07de8 <THREAD_Start>, thread_errno = 0, thread_h_errno = 0, signal_stack = 0xdbe21000, exit_stack = 0x0, emu_data = 0x0, last_error = 0, debug_cb = 0x0, debug_thread = 0, pcontext = 0x0, cur_stack = 0, ThunkConnect = 0, NegStackBase = 0, current_ss = 0, pad2 = 0, ss_table = 0x0, thunk_ss = 0, pad3 = 0, pad4 = {0 <repeats 15 times>}, CurrentLocale = 0, pad5 = {0 <repeats 48 times>}, delta_priority = 0, unknown4 = {0, 0, 0, 0, 0, 0, 0}, create_data = 0x0, suspend_count = 0, entry_point = 0xdcf0e50c, entry_arg = 0xdd5c9bd0, unknown5 = {0, 0, 0, 0}, sys_count = {0, 0, 0, 0}, sys_mutex = {0x0, 0x0, 0x0, 0x0}, unknown6 = {0, 0, 0, 0, 0}, code_page = 0, unused = {0, 0}, gs_sel = 0, request_fd = 14, reply_fd = -1, wait_fd = {-1, -1}, debug_info = 0xdc044000, pthread_data = 0x0, pending_list = 0x0, driver_data = 0x0, dpmi_vif = 0, vm86_pending = 0, vm86_ptr = 0x0, pad6 = {0 <repeats 624 times>}, StaticUnicodeString = {Length = 0, MaximumLength = 522, Buffer = 0xdc043c00}, StaticUnicodeBuffer = {0 <repeats 261 times>}, stack_base = 0xdbe20000, tls_array = {0x0 <repeats 64 times>}, pad8 = {0, 0, 0}, ReservedForNtRpc = 0x0, pad9 = { 0 <repeats 24 times>}, ErrorInfo = 0x0} (gdb) step Starting New Thread Via thr_create stack base = dbe20000 size =2240512 282 _lwp_makecontext( &context, (void(*)(void *))SYSDEPS_StartThread, teb, (gdb) 284 sigprocmask(SIG_SETMASK, NULL, &context.uc_sigmask); (gdb) 285 err=_lwp_create( &context, LWP_DETACHED, &new_lwp ) ; (gdb) print context $3 = {uc_flags = 4, uc_link = 0x50, uc_sigmask = {__sigbits = {1, 0, 0, 0}}, uc_stack = {ss_sp = 0x0, ss_size = 0, ss_flags = 0}, uc_mcontext = {gregs = {0, 143, 31, 31, 0, 0, -603705352, 9, -581817680, -593636687, 9, -581817668, 32, 0, -575639696, 23, -577633087, -603705360, 31}, fpregs = {fp_reg_set = {fpchip_state = {state = {-581133360, 0, -581817304, -584563419, 0, 0, 0, 0, -576773248, -575357312, -581817576, -581817562, -581817772, -575738902, -576456548, -593636687, 9, -581817568, 32, 0, -577515520, -577924375, -577515520, -581817768, -577997369, 11, -576243124}, status = -581817728}, fp_emul_space = { fp_emul = "Ð\233\\Ý\0\0\0\0(,RÝ%E(Ý", '\0' <repeats 16 times>, "\200#\237Ý\200¾´Ý\030+RÝ&+RÝT*RÝêë®Ý\234ø£Ý±Ò\235Ü\t\0\0\0 + RÝ \0\0\0\0\0\0\0\0Ð\223Ýé\222\215Ý\0Ð\223ÝX*RÝÇu\214Ý\v\0\0\0L:§Ý\200*RÝÿâ\214Ý\016&²ÝÈ-\224Ý\0Ð\223Ý`Ý\a\bÿâ\214Ý\020Þ\a\b\0\0\0\0\2 24\024\224Ý\0\0\0\0\030Þ\a\b\0Ð\223Ý\234*RÝ{ú\221Ý\210\024\224Ý\0Ð\223Ý°*RÝGÝ\214Ý\026ä°ÝÁä°Ý\001\0\0\0~\e²Ý;ß\a\bW\0"..., fp_epad = "\a\b"}, f_fpregs = {-581133360, 0, -581817304, -584563419, 0, 0, 0, 0, -576773248, -575357312, -581817576, -581817562, -581817772, -575738902, -576456548, -593636687, 9, -581817568, 32, 0, -577515520, -577924375, -577515520, -581817768, -577997369, 11, -576243124, -581817728, -577969409, -575527410, -577491512, -577515520, 134733152, -577969409, 134733328, 0, -577497964, 0, 134733336, -577515520, -581817700, -577635717, -577497976, -577515520, -581817680, -577970873, -575609834, -575609663, 1, -575530114, 134733627, 87, 1, 87, -575322962, 1465002724, -575357312, 134733628, 4096, -581817592, -575525247, 134733336}}, f_wregs = {-604889088, 4096, 87, -604889088, 134733336, 64, -575357312, -581817488, -605945856, -581817556, -575708909, -1, -581817544, -581817540, 320, -581817488, -575357312, -581817488, -581817524, -575708957, -1, -604889088, 4096, 320, -581817488, -575357312, -581817472, -575636289, -604889088, 1, 320, -581817488, 8192}}}, uc_filler = {-605937664, 2248704, 64, -575357312, 10}}

2 2

Info on windows server 2003 (new APIs)
by Eric Pouech June 22, 2003

June 22, 2003

http://msdn.microsoft.com/msdnmag/issues/03/06/WindowsServer2003/default.as… well, not too many surprises here (most of the new APIs already existed in XP) A+ -- Eric Pouech

1 0

Re: dmusic: framework for file loading
by Andreas Mohr June 22, 2003

June 22, 2003

On Sun, Jun 22, 2003 at 03:12:43PM +0200, Rok Mandeljc wrote: > As I've mentioned, we'll need a function for loading chunks from dmusic > files. I tried to write one, and here's result; it's not very nice, but > it works (sort of). > At the time being, it only "loads" and displays data > (--debugmsg=+dmfile for debug and --debugmsg=+dmfiledat for the display > of data). I couldn't make it load data into IDirectMusic*Impl > interfaces, because whatever I did, exception occured (maybe someone > more familiar with this could do this (Raphael?)). Also, if someone has > more robust and simpler function, please tell me. > DMUSIC_FillSegmentFromFileHandle loads sample.sgt from DX SDK > completely... however, i didn't try the other. > > Also "fixed" a problem I've encountered while running 3DAudio.exe (from > SDK). One of the latest patches added this clause: > > if (!ppDirectSound) > IDirectSound_Release(*ppDirectSound); > > I don't know why, but it causes exception (i've commented it). Would you PLEASE remove the ! instead of commenting the whole stupid thing!? Aargh, too easy... ;) Andreas Mohr

1 0

Patch ntdll/kernel32: #27 take III, possible console regression
by Jukka Heinonen June 22, 2003

June 22, 2003

It seems that this patch (ntdll/kernel32: #27 take III) makes console input handles use edge triggered semantics. Which means that these handles only signal when new input is queued and not when console input buffer has unread data. This breaks winedos console handling, which would have been rather easy to fix if I had not found out that MSDN quite clearly states that console input handles use level triggered semantics: http://msdn.microsoft.com/library/en-us/dllproc/base/synchronization_object…: Console input: Created when a console is created. The handle to console input is returned by the CreateFile function when CONIN$ is specified, or by the GetStdHandle function. Its state is set to signaled when there is unread input in the console's input buffer, and set to nonsignaled when the input buffer is empty. So, it looks like the kernel patch is wrong and introduces a regression. It could be that MSDN documentation is incorrect but I would like to see some test reports before I'm prepared to believe that. As far as I know, Win95 console handles really may use edge triggered semantics (or no signalling at all), but I think Wine consoles ought to follow NT semantics. -- Jukka Heinonen <http://www.iki.fi/jhei/>

2 1

unknown pseudo op
by Robert Lunnon June 22, 2003

June 22, 2003

In dlls/glu32 winebuild keeps generating glu32_spec.c using a .half pseudo op for the ordinals, but gas knows nothing about a .half pseudo op. Cant even find this text in winebuild, .long seems to be used for listing ordinals. Can anyone give me a clue to this mystery (GCC 2.95.3 BTW)

1 0

GetTimeOfDay on Windows
by Steven Edwards June 20, 2003

June 20, 2003

Hello, What do you think about me adding a case for GetTimeOfDay to libwine for the Windows port? I dont expect every case of it to be reimplemented from scratch and it seems that winsock2.h defines typedef struct timeval { long tv_sec; long tv_usec; } timeval; http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/wi… /* * Defines gettimeofday * * Based on timeval.h by Wu Yongwei * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public * License as published by the Free Software Foundation; either * version 2.1 of the License, or (at your option) any later version. * * This library is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * Lesser General Public License for more details. * * You should have received a copy of the GNU Lesser General Public * License along with this library; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #include "config.h" #include "wine/port.h" #ifndef HAVE_GETTIMEOFDAY __inline int gettimeofday(struct timeval *tv, struct timezone *tz) #ifdef _WINDOWS { FILETIME ft; LARGE_INTEGER li; __int64 t; static int tzflag; if (tv) { GetSystemTimeAsFileTime(&ft); li.LowPart = ft.dwLowDateTime; li.HighPart = ft.dwHighDateTime; t = li.QuadPart; /* In 100-nanosecond intervals */ t -= EPOCHFILETIME; /* Offset to the Epoch time */ t /= 10; /* In microseconds */ tv->tv_sec = (long)(t / 1000000); tv->tv_usec = (long)(t % 1000000); } if (tz) { if (!tzflag) { _tzset(); tzflag++; } tz->tz_minuteswest = _timezone / 60; tz->tz_dsttime = _daylight; } return 0; #else /* !defined(_WINDOWS) */ errno = ENOSYS; return -1; #endif /* _WINDOWS */ #endif /* HAVE_GETTIMEOFDAY */ } __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com

1 0

Re: [OPENGL] Compilation fixes on some b0rken headers
by Lionel Ulmer June 20, 2003

June 20, 2003

On Fri, Jun 20, 2003 at 05:22:22AM +0200, Sylvain Petreolle wrote: > A 50k patch ?? Well, and so ? If I sent it as a compressed file, the 'all patches need to be readable junkies' will complain. And well, it's plain text, so even people with dial-up will download it pretty fast thanks to line compression :-) Lionel PS: '50 lines quoted for one line reply ?????' (and using the dreaded Outlook quoting convention) -- Lionel Ulmer - http://www.bbrox.org/

2 2

Re: ntdll/kernel32: #27 take II
by Alexandre Julliard June 20, 2003

June 20, 2003

Eric Pouech <pouech-eric(a)wanadoo.fr> writes: > This is a second take at console handles in ntdll. It includes > corrections for latest Alexandre's remarks. Much better, thanks. Just a minor point: the server must not use INVALID_HANDLE_VALUE, the proper value for invalid handles in the server is 0. Also please don't make server calls inside server calls (like the ReleaseSemaphore call in write_console_input). -- Alexandre Julliard julliard(a)winehq.com

1 0

[D3D] Xvidmode and surface locking
by OverrideX June 20, 2003

June 20, 2003

Ok, I recently started using System Shock 2 fullscreen with xvidmode enabled in my wine config, and here's something strange. When xvidmode is enabled, and I'm in a game and press esc to go to the menu, then esc again to return to the game, or load another save or go through a bulkhead/elevator and cause it to load another level, when it returns to the game the 3D area is completely black, though the HUD/inventory and brackets around items all shows up. This happens with a cvs from 2003-06-08 and also with a cvs from 2003-05-17, however if I don't patch 2003-05-17 with the surface locking the screen doesn't black when loading a saved game or moving between levels, etc. (of course then there's no hud or anything without the surface locking) So basically it's like you can only load 1 saved game, then the next area you go to or saved game you restore you need to save and restart the game for it to go away. Sorry I didn't notice this sooner when testing it out for you :) If you need any tracing done I'd be glad to, just tell me what ya need, also if you want a demo of ss2 I could give you a link to that too.... cheers -Dan -- OverrideX <overridex(a)punkass.com> GPG Key Fingerprint = 4AD5 CE9C D7C8 0069 BDD3 7F72 3AB2 642A 5A5D EB89 In spite of everything, I still believe that people are good at heart. -- Ann Frank

2 3

Wintab dll: Status report.
by Robert North June 20, 2003

June 20, 2003

Ok, I've done some preliminary testing, and fixed obvious bugs that have arisen. What I found, and could fix: Sometimes a badly configured tablet can generate X errors on the XOpenDevice method. Fixed by ensuring tablet driver was functional. I don't know if the errors need to be caught, or not, but I think they were causing crashes. This is probably related to synchonous/asynchonous X modes. In Photoshop, an infinite loop in method FindOpenContext when attepting to traverse the wintab context chain. In Painter, a number of methods didn't handle NULL prameters properly, resulting in various crashes. Wintab uses NULL paramters to signify a query for size of available data, or to signify a request to flush the Wintab packet queue. Aric, I'm wondering if I should really be fixing these things, as these look like the kind of bugs Code Weavers will have fixed in the normal course of product support. After fixing these issues, The following remain: 1. Photoshop doesn't seem to respond to pressure. 2. Painter receives wintab events, but coordinates are extreme: only see lines from one side of drawing to another. 3. Maybe some further research into the errors from XOpenDevice. I'm not convinced it is a problem. Aric, are these the kind of bugs you were seeing with Painter? I'm suspicious of the Wintab packet building code, as it has to build a C data struct on the fly. Looking at the code though, I can't see anything that could be going wrong. It could also be a scaling issue, where the scales deduced from X are wrong (I remember being suspicious of some of the values returned by the wacom driver). I've got tons of trace code that runs as a wrapper round wintab on win98, and will move some of this into the wine impl for more testing. I hope this will help solve the remaining bugs. I think in the light of the crashing bugs, Aric's patch shouldn't go in as-is. If people want, I could post up a patch with the fixes I've added so far. That's all for now. -Rob.

3 3