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

Re: Bidi B2 - GetCharacterPlacement order array

by Dimitrie O. Paun

On Mon, 2 Jun 2003, Shachar Shemesh wrote: > Seems like it's not my day for URLs. > > http://shemesh.biz/lecures.html ^t^ No, it really isn't :P http://shemesh.biz/lectures.html -- Dimi.

June 2, 2003

Re: Bidi B2 - GetCharacterPlacement order array

by Shachar Shemesh

Shachar Shemesh wrote: > David Laight wrote: > >> Be aware that strncyp() rarely DTRT, in particular: >> - it doesn't guarantee to zero terminate the target >> - it is required to zero fill the target buffer >> Neither of these is usually desirable. >> > Well aware of both. Thanks. I'm routinely giving lectures about them > (http://shemesh.biz/lectures) Seems like it's not my day for URLs. http://shemesh.biz/lecures.html Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/

June 2, 2003

Re: Bidi B2 - GetCharacterPlacement order array

by Shachar Shemesh

David Laight wrote: >Be aware that strncyp() rarely DTRT, in particular: >- it doesn't guarantee to zero terminate the target >- it is required to zero fill the target buffer >Neither of these is usually desirable. > Well aware of both. Thanks. I'm routinely giving lectures about them (http://shemesh.biz/lectures) Since the buffer is not zero terminated to begin with, 1 is not a problem. Since the loop that strncpy replaces copied n bytes over from the old buffer to the new one, neither is 2. This does impose the theoretical problem that if the original string WAS zero terminated, and the NULL was not the last WCHAR in the buffer, we change the semantics. I doubt very much, however, that you will find a program that relies on this. I don't even know what Windows does under the same circumstances. >Many systems have a strlcpy() function which does what you want much >more often. > Well aware of that too. strncpy is really the most fitting here. Trust me. >OTOH is the target buffer can be too short with valid data, they you >need to (typically) dynamically allocate a buffer. > Not applicable to GetCharacterPlacement. > David > > Thanks. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/

June 2, 2003

Re: Bidi B2 - GetCharacterPlacement order array

by David Laight

> >>+ if (lpResults->lpOutString) > >>+ for (i = 0; i < nSet && lpString[i] != 0; ++i) > >>+ lpResults->lpOutString[i] = lpString[i]; > >> > >> > > > >What about a strncpy here: Be aware that strncyp() rarely DTRT, in particular: - it doesn't guarantee to zero terminate the target - it is required to zero fill the target buffer Neither of these is usually desirable. Many systems have a strlcpy() function which does what you want much more often. OTOH is the target buffer can be too short with valid data, they you need to (typically) dynamically allocate a buffer. David -- David Laight: david(a)l8s.co.uk

June 2, 2003

Re: Wierd random spew to the terminal

by Carlos Lozano

El lun, 02 de jun de 2003, a las 16:03, Mike Hearn escribio: > Hmm, I think quite a few of us have seen this now. Well, it just > happened again so this time I attached gdb and tried to get a backtrace > to see what was going on. > I have seen it. Sometimes i can read the message: "wine client error" Regards, Carlos. -- ___ _ \ | / Consulting | . |._ _ _| | ___ ___ ___ http://www.andago.com | || ' |/ . |<_> |/ . |/ . \__ GNU/Linux |_|_||_|_|\___|<___|\_. |\___/ _ \ __|\ \ / Carlos A. Lozano <___'/ | \ -_) __/\__ \ > < -_) [ carlos.lozano(a)andago.com ]\___|_| ____/ _/\_\___| [ calb(a)epsxe.com ] http://www.ePSXe.com

June 2, 2003

Re: Wierd random spew to the terminal

by Michael Stefaniuc

On Mon, Jun 02, 2003 at 04:03:49PM +0100, Mike Hearn wrote: > Hmm, I think quite a few of us have seen this now. Well, it just > happened again so this time I attached gdb and tried to get a backtrace > to see what was going on. > > I found a very curious thing.... the stack trace was huge, in fact, it > had 3162 frames. As you might expect it was recursive. It looked like > this: I once had this problem and it was triggered by an unimplemented function in msvcrt. Did you tried running with --debugmsg +seh? But better redirect the output to a file. bye michael > > #3141 <signal handler called> > #3142 0x4009e977 in rwlock_real_init (rwlock=0x42126020) at > ../../include/winbase.h:1932 > #3143 0x4009ea48 in __pthread_rwlock_rdlock (rwlock=0x42126020) at > ../../scheduler/pthread.c:547 > #3144 0x4202365a in __dcigettext () from /lib/i686/libc.so.6 > #3145 0x42022ed5 in dcgettext () from /lib/i686/libc.so.6 > #3146 0x4207a4b7 in strerror_r () from /lib/i686/libc.so.6 > #3147 0x4206148b in perror () from /lib/i686/libc.so.6 > #3148 0x40099259 in server_protocol_perror (err=0x400bdc31 "read") at > ../../scheduler/client.c:134 > #3149 0x40099388 in read_reply_data (buffer=0x405ca5a4, size=64) at > ../../scheduler/client.c:195 > #3150 0x400993de in wine_server_call (req_ptr=0x405ca5a4) at > ../../scheduler/client.c:209 > #3151 0x400a8653 in send_debug_event (rec=0x405ca6a8, first_chance=1, > context=0x405ca71c) > at exception.c:137 > #3152 0x400a87fa in EXC_RtlRaiseException (rec=0x405ca6a8, > context=0x405ca71c) at exception.c:195 > #3153 0x400b6e48 in do_segv (context=0x405ca71c, trap_code=14, cr2=0x18, > err_code=4) > at signal_i386.c:814 > #3154 0x400b7324 in segv_handler (__signal=11, __context= > {sc_gs = 143, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh > = 0, sc_ds = 43, __dsh = 0, sc_edi = 1108452444, sc_esi = 1108500512, > sc_ebp = 1079815400, sc_esp = 1079815380, sc_ebx = 1074654520, sc_edx = > 1108500512, sc_ecx = 1108481382, sc_eax = 0, sc_trapno = 14, sc_err = 4, > sc_eip = 1074391415, sc_cs = 35, __csh = 0, sc_eflags = 66050, > esp_at_signal = 1079815380, sc_ss = 43, __ssh = 0, i387 = 0, oldmask = > 2415929859, cr2 = 24}) at signal_i386.c:436 > #3155 <signal handler called> > > So it would appear that there is a crash in the exception handler which > just goes round and round, and clearly at some point garbage is written > to stdout/stderr. > > Unfortunately my code-fu is not strong in areas related to > threading/exception handling, so I don't really know what's going wrong, > except that it seems there is a problem in rwlock_real_init (in fact the > line number it gives is in GetProcessHeap()). > > Well, I thought somebody may find it useful. BTW, after I attached to > wine (ie stopped it) something was still typing out letter by letter > "xtermxtermxterm" over and over again.... wake up neo :) > > thanks -mike > -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

June 2, 2003

Re: Wierd random spew to the terminal

by Mike Hearn

> I once had this problem and it was triggered by an unimplemented > function in msvcrt. Did you tried running with --debugmsg +seh? But > better redirect the output to a file. Nope: wine client error:0: trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x4009e977 trace:seh:EXC_RtlRaiseException info[0]=00000000 trace:seh:EXC_RtlRaiseException info[1]=00000018 It's just a plain old access violation... -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

June 2, 2003

Wierd random spew to the terminal

by Mike Hearn

Hmm, I think quite a few of us have seen this now. Well, it just happened again so this time I attached gdb and tried to get a backtrace to see what was going on. I found a very curious thing.... the stack trace was huge, in fact, it had 3162 frames. As you might expect it was recursive. It looked like this: #3141 <signal handler called> #3142 0x4009e977 in rwlock_real_init (rwlock=0x42126020) at ../../include/winbase.h:1932 #3143 0x4009ea48 in __pthread_rwlock_rdlock (rwlock=0x42126020) at ../../scheduler/pthread.c:547 #3144 0x4202365a in __dcigettext () from /lib/i686/libc.so.6 #3145 0x42022ed5 in dcgettext () from /lib/i686/libc.so.6 #3146 0x4207a4b7 in strerror_r () from /lib/i686/libc.so.6 #3147 0x4206148b in perror () from /lib/i686/libc.so.6 #3148 0x40099259 in server_protocol_perror (err=0x400bdc31 "read") at ../../scheduler/client.c:134 #3149 0x40099388 in read_reply_data (buffer=0x405ca5a4, size=64) at ../../scheduler/client.c:195 #3150 0x400993de in wine_server_call (req_ptr=0x405ca5a4) at ../../scheduler/client.c:209 #3151 0x400a8653 in send_debug_event (rec=0x405ca6a8, first_chance=1, context=0x405ca71c) at exception.c:137 #3152 0x400a87fa in EXC_RtlRaiseException (rec=0x405ca6a8, context=0x405ca71c) at exception.c:195 #3153 0x400b6e48 in do_segv (context=0x405ca71c, trap_code=14, cr2=0x18, err_code=4) at signal_i386.c:814 #3154 0x400b7324 in segv_handler (__signal=11, __context= {sc_gs = 143, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh = 0, sc_ds = 43, __dsh = 0, sc_edi = 1108452444, sc_esi = 1108500512, sc_ebp = 1079815400, sc_esp = 1079815380, sc_ebx = 1074654520, sc_edx = 1108500512, sc_ecx = 1108481382, sc_eax = 0, sc_trapno = 14, sc_err = 4, sc_eip = 1074391415, sc_cs = 35, __csh = 0, sc_eflags = 66050, esp_at_signal = 1079815380, sc_ss = 43, __ssh = 0, i387 = 0, oldmask = 2415929859, cr2 = 24}) at signal_i386.c:436 #3155 <signal handler called> So it would appear that there is a crash in the exception handler which just goes round and round, and clearly at some point garbage is written to stdout/stderr. Unfortunately my code-fu is not strong in areas related to threading/exception handling, so I don't really know what's going wrong, except that it seems there is a problem in rwlock_real_init (in fact the line number it gives is in GetProcessHeap()). Well, I thought somebody may find it useful. BTW, after I attached to wine (ie stopped it) something was still typing out letter by letter "xtermxtermxterm" over and over again.... wake up neo :) thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

June 2, 2003

Re: Merge of WineX's (LGPL licensed) wininet.dll code

by Mike Hearn

Well, I'm spending my fun afternoon trying to get IE to install in Wine (it breaks in a new and interesting way every time I try this). Before the patch, it didn't work, couldn't contact download sites. After the patch, it still doesn't work, and I get this fixme: fixme:wininet:InternetReadFile This shouldn't be here! We don't support this kind of connection anymore. Must use NETCON functions, especially if using SSL Which seems a bit of a bummer, if IE6 setup needs that type of connection I think we should still support it really...... I think the problem might be lack of proxy workingness. Am investigating now. Would be nice to lift proxy details from the http_proxy variable in future.... One last thing, the patch seemed to have a lot of whitespace no-ops, running diff with -bB should eliminate some. thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

June 2, 2003

Status page update #1

by Tom

Hello, I am working on another Status page update and here is a list of Component's that currently dont have a primary worker asighned. If you are a worker on any of these Component's can you let me know and I will add you in as the worker. Also if you are aware of a Status % work done on any of these can you let me know. I am aware that some Component's are not being worked on at all times... I would just like to get all workers in place. Also if your listed as a worker and your not the current worker or don't plan to work on a Component in the future I will remove you if you wish. Thanks Tom ----------------- Wine Status - Core : http://www.winehq.org/?page=status_wine Registry handling X11 display/window driver Clipboard handling Standard Windows Controls VxDs CPU emulation Multi-user support Initial registry contents Initial directory structure Initial INI files Wine Status DLL's : http://www.winehq.org/?page=status_dlls comdlg32: Common Dialogs riched32: Rich Text Control tapi32: Telephony API (TAPI) rasapi32: Dial-Up Networking (DUN) and Remote Access Service (RAS) quartz: DirectShow core wing: WinG 16-bit game library olecli32: OLE client library olesvr32: OLE server library oledlg: OLE user interface odbc32: ODBC Database Manager wnaspi32: Advanced SCSI Peripheral Interface

June 2, 2003