October 2007 - Wine-Devel - list.winehq.org

Re: mshtml: Added support for installing Gecko from build dir.

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > - static const char gecko_dir[] = "/gecko/"; > - > - data_dir = wine_get_data_dir(); > - if(!data_dir) return FALSE; > + if((data_dir = wine_get_data_dir())) > + subdir = "/gecko/"; > + else if((data_dir = wine_get_build_dir())) > + subdir = "/dlls/mshtml/"; I don't think this file should be inside the build dir, it's not something that can be easily regenerated. Maybe we should look for it in $build_dir/.. ? -- Alexandre Julliard julliard(a)winehq.org

Oct. 18, 2007

Re: widl [3/4]: Remove printf format strings that aren't really format strings.

by Michael Stefaniuc

Dan Hipschman wrote: > This is just a minor cleanup patch. Even if we're definitely sure a > string doesn't contain any % signs, it's still better not to use it as a > printf format string. fputs() would be a faster alternative to that. Though i doubt that matters in this case. bye michael > --- > tools/widl/typegen.c | 4 ++-- > tools/widl/widl.c | 6 +++--- > 2 files changed, 5 insertions(+), 5 deletions(-) > > diff --git a/tools/widl/typegen.c b/tools/widl/typegen.c > index bf24d3f..53ec78c 100644 > --- a/tools/widl/typegen.c > +++ b/tools/widl/typegen.c > @@ -2501,7 +2501,7 @@ void print_phase_basetype(FILE *file, int indent, enum remoting_phase phase, > fprintf(file, " *)_StubMsg.Buffer = *"); > else > fprintf(file, " *)_StubMsg.Buffer = "); > - fprintf(file, varname); > + fprintf(file, "%s", varname); > fprintf(file, ";\n"); > } > else if (phase == PHASE_UNMARSHAL) > @@ -2510,7 +2510,7 @@ void print_phase_basetype(FILE *file, int indent, enum remoting_phase phase, > print_file(file, indent, ""); > else > print_file(file, indent, "*"); > - fprintf(file, varname); > + fprintf(file, "%s", varname); > if (pass == PASS_IN && is_ptr(type)) > fprintf(file, " = ("); > else > diff --git a/tools/widl/widl.c b/tools/widl/widl.c > index 53c9e29..37f1a5e 100644 > --- a/tools/widl/widl.c > +++ b/tools/widl/widl.c > @@ -422,13 +422,13 @@ int main(int argc,char *argv[]) > idfile_name = xstrdup(optarg); > break; > case 'V': > - printf(version_string); > + printf("%s", version_string); > return 0; > case 'W': > pedantic = 1; > break; > default: > - fprintf(stderr, usage); > + fprintf(stderr, "%s", usage); > return 1; > } > } > @@ -458,7 +458,7 @@ int main(int argc,char *argv[]) > input_name = xstrdup(argv[optind]); > } > else { > - fprintf(stderr, usage); > + fprintf(stderr, "%s", usage); > return 1; > } > > > -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 -------------------------------------------------------------------- Reg. Adresse: Red Hat GmbH, Hauptstätter Strasse 58, 70178 Stuttgart Handelsregister: Amtsgericht Stuttgart HRB 153243 Geschäftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Werner Knoblich

Oct. 18, 2007

Re: msi: make the WriteEnvironmentStrings handling of [~] a bit better

by Mikolaj Zalewski

EA Durbin wrote: > The compiler complains at this line about lstrlenW being passed an incompatible pointer type > > + else if (lstrlenW(value) >= prefix_len) > > > > should it be lstrlenW(*value) ? > Thanks for noticing it. Mikołaj Zalewski

Oct. 18, 2007

Re: [PATCH] wininet: Close sockets open in http requests

by Misha Koshelev

On Wed, 2007-10-17 at 17:10 -0700, Nigel Liang wrote: > On 10/17/07, Misha Koshelev <mk144210(a)bcm.edu> wrote: > > On Wed, 2007-10-17 at 17:10 -0500, Misha Koshelev wrote: > > > > n 10/13/07, Nigel Liang <ncliang at gmail.com> wrote: > > > > > Hi, > > > > > > > > > > Http requests open sockets and forget to close them. Left running over a long > > > > > period, the socket file descriptor starts getting large. Once it exceeds > > > > > FD_SETSIZE, the behavior becomes unpredictable and results in funcky crashes. > > > > > > > > > > -Nigel > > > > > > > > > > --- > > > > > dlls/wininet/internet.c | 3 +++ > > > > > 1 files changed, 3 insertions(+), 0 deletions(-) > > > > > > > > > > diff --git a/dlls/wininet/internet.c b/dlls/wininet/internet.c > > > > > index 0edca74..8e3a98e 100644 > > > > > --- a/dlls/wininet/internet.c > > > > > +++ b/dlls/wininet/internet.c > > > > > @@ -1014,6 +1014,9 @@ BOOL WINAPI InternetCloseHandle(HINTERNE > > > > > return FALSE; > > > > > } > > > > > > > > > > + if (lpwh->htype == WH_HHTTPREQ) > > > > > + NETCON_close(&((LPWININETHTTPREQW)lpwh)->netConnection); > > > > > + > > > > > WININET_Release( lpwh ); > > > > > WININET_FreeHandle( hInternet ); > > > > > > > > > > -- > > > > > 1.4.1 > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > This patch was sent 4 days ago and it hasn't gone in yet. Could anyone > > > > give me some comments on it? Dan filed bug 10032 which is related to > > > > this. While we shouldn't be using select() on high FDs for networking, > > > > this patch closes the sockets that were open by http requests to avoid > > > > getting to high FDs... > > > > > > > > Thanks, > > > > -Nigel > > > > > > Hi, well looking over this very quickly right off the bat it does not seem > > > correct to me. WININET_Release will call the close_connection method of the > > > handle if it is defined, and for WH_HHTTPREQ this is HTTP_CloseConnection, > > > which does call NETCON_Close along with sending all the proper status notifications, > > > etc. > > > > > > So if in fact NETCON_Close is _not_ being called for some reason, you need to track > > > down where involving those functions either why the proper one is not > > > getting called (if that is the case) or if that function somehow needs to call > > > NETCON_Close when it doesn't. > > > > > > Misha > > > > Actually, thinking about this a little more, if this is indeed happening > > (NETCON_close not getting called) then likely this is a reference count > > problem for the object, and thus the proper fix would be to find where > > the reference count is being incremented but not appropriately > > decremented, as info->close_connection only gets called if the reference > > count of the object is zero. In my own experience, there have been quite > > a few places where reference counts were incremented and not decremented > > appropriately in wininet (the ones I ran into I believe are patched now > > though). > > > Hi, > > Yep, you were right. There was a missing call to WININET_Release. > Found it and submitted a new patch: > http://www.winehq.org/pipermail/wine-patches/2007-October/045337.html > > Thanks! > -Nigel Glad my hours of staring at wininet led to something useful :) I looked at your new patch and it looks good to me. Now if I could just figure out bug 9922 (or even knew if it still occurs since I can't reproduce it)... Misha

Oct. 18, 2007

RE: msi: make the WriteEnvironmentStrings handling of [~] a bit better

by EA Durbin

The compiler complains at this line about lstrlenW being passed an incompatible pointer type + else if (lstrlenW(value) >= prefix_len) should it be lstrlenW(*value) ? _________________________________________________________________ Climb to the top of the charts! Play Star Shuffle: the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_oct

Oct. 18, 2007

Re: [PATCH] wininet: Close sockets open in http requests

by Nigel Liang

On 10/17/07, Misha Koshelev <mk144210(a)bcm.edu> wrote: > On Wed, 2007-10-17 at 17:10 -0500, Misha Koshelev wrote: > > > n 10/13/07, Nigel Liang <ncliang at gmail.com> wrote: > > > > Hi, > > > > > > > > Http requests open sockets and forget to close them. Left running over a long > > > > period, the socket file descriptor starts getting large. Once it exceeds > > > > FD_SETSIZE, the behavior becomes unpredictable and results in funcky crashes. > > > > > > > > -Nigel > > > > > > > > --- > > > > dlls/wininet/internet.c | 3 +++ > > > > 1 files changed, 3 insertions(+), 0 deletions(-) > > > > > > > > diff --git a/dlls/wininet/internet.c b/dlls/wininet/internet.c > > > > index 0edca74..8e3a98e 100644 > > > > --- a/dlls/wininet/internet.c > > > > +++ b/dlls/wininet/internet.c > > > > @@ -1014,6 +1014,9 @@ BOOL WINAPI InternetCloseHandle(HINTERNE > > > > return FALSE; > > > > } > > > > > > > > + if (lpwh->htype == WH_HHTTPREQ) > > > > + NETCON_close(&((LPWININETHTTPREQW)lpwh)->netConnection); > > > > + > > > > WININET_Release( lpwh ); > > > > WININET_FreeHandle( hInternet ); > > > > > > > > -- > > > > 1.4.1 > > > > > > > > > > > > > > Hi, > > > > > > This patch was sent 4 days ago and it hasn't gone in yet. Could anyone > > > give me some comments on it? Dan filed bug 10032 which is related to > > > this. While we shouldn't be using select() on high FDs for networking, > > > this patch closes the sockets that were open by http requests to avoid > > > getting to high FDs... > > > > > > Thanks, > > > -Nigel > > > > Hi, well looking over this very quickly right off the bat it does not seem > > correct to me. WININET_Release will call the close_connection method of the > > handle if it is defined, and for WH_HHTTPREQ this is HTTP_CloseConnection, > > which does call NETCON_Close along with sending all the proper status notifications, > > etc. > > > > So if in fact NETCON_Close is _not_ being called for some reason, you need to track > > down where involving those functions either why the proper one is not > > getting called (if that is the case) or if that function somehow needs to call > > NETCON_Close when it doesn't. > > > > Misha > > Actually, thinking about this a little more, if this is indeed happening > (NETCON_close not getting called) then likely this is a reference count > problem for the object, and thus the proper fix would be to find where > the reference count is being incremented but not appropriately > decremented, as info->close_connection only gets called if the reference > count of the object is zero. In my own experience, there have been quite > a few places where reference counts were incremented and not decremented > appropriately in wininet (the ones I ran into I believe are patched now > though). > Hi, Yep, you were right. There was a missing call to WININET_Release. Found it and submitted a new patch: http://www.winehq.org/pipermail/wine-patches/2007-October/045337.html Thanks! -Nigel

Oct. 18, 2007

Priority/severity of test suite hangs

by Dan Kegel

I'm going to start filing bugs for anything that makes the test suite hang, and I'm going to lash out and give them unreasonably high priority and severity. There's just no excuse for a test suite that can't run to completion. -- Wine for Windows ISVs: http://kegel.com/wine/isv

Oct. 17, 2007

Re: [PATCH] wininet: Close sockets open in http requests

by Misha Koshelev

On Wed, 2007-10-17 at 17:10 -0500, Misha Koshelev wrote: > > n 10/13/07, Nigel Liang <ncliang at gmail.com> wrote: > > > Hi, > > > > > > Http requests open sockets and forget to close them. Left running over a long > > > period, the socket file descriptor starts getting large. Once it exceeds > > > FD_SETSIZE, the behavior becomes unpredictable and results in funcky crashes. > > > > > > -Nigel > > > > > > --- > > > dlls/wininet/internet.c | 3 +++ > > > 1 files changed, 3 insertions(+), 0 deletions(-) > > > > > > diff --git a/dlls/wininet/internet.c b/dlls/wininet/internet.c > > > index 0edca74..8e3a98e 100644 > > > --- a/dlls/wininet/internet.c > > > +++ b/dlls/wininet/internet.c > > > @@ -1014,6 +1014,9 @@ BOOL WINAPI InternetCloseHandle(HINTERNE > > > return FALSE; > > > } > > > > > > + if (lpwh->htype == WH_HHTTPREQ) > > > + NETCON_close(&((LPWININETHTTPREQW)lpwh)->netConnection); > > > + > > > WININET_Release( lpwh ); > > > WININET_FreeHandle( hInternet ); > > > > > > -- > > > 1.4.1 > > > > > > > > > > Hi, > > > > This patch was sent 4 days ago and it hasn't gone in yet. Could anyone > > give me some comments on it? Dan filed bug 10032 which is related to > > this. While we shouldn't be using select() on high FDs for networking, > > this patch closes the sockets that were open by http requests to avoid > > getting to high FDs... > > > > Thanks, > > -Nigel > > Hi, well looking over this very quickly right off the bat it does not seem > correct to me. WININET_Release will call the close_connection method of the > handle if it is defined, and for WH_HHTTPREQ this is HTTP_CloseConnection, > which does call NETCON_Close along with sending all the proper status notifications, > etc. > > So if in fact NETCON_Close is _not_ being called for some reason, you need to track > down where involving those functions either why the proper one is not > getting called (if that is the case) or if that function somehow needs to call > NETCON_Close when it doesn't. > > Misha Actually, thinking about this a little more, if this is indeed happening (NETCON_close not getting called) then likely this is a reference count problem for the object, and thus the proper fix would be to find where the reference count is being incremented but not appropriately decremented, as info->close_connection only gets called if the reference count of the object is zero. In my own experience, there have been quite a few places where reference counts were incremented and not decremented appropriately in wininet (the ones I ran into I believe are patched now though). Misha

Oct. 17, 2007

Re: [PATCH] wininet: Close sockets open in http requests

by Misha Koshelev

> n 10/13/07, Nigel Liang <ncliang at gmail.com> wrote: > > Hi, > > > > Http requests open sockets and forget to close them. Left running over a long > > period, the socket file descriptor starts getting large. Once it exceeds > > FD_SETSIZE, the behavior becomes unpredictable and results in funcky crashes. > > > > -Nigel > > > > --- > > dlls/wininet/internet.c | 3 +++ > > 1 files changed, 3 insertions(+), 0 deletions(-) > > > > diff --git a/dlls/wininet/internet.c b/dlls/wininet/internet.c > > index 0edca74..8e3a98e 100644 > > --- a/dlls/wininet/internet.c > > +++ b/dlls/wininet/internet.c > > @@ -1014,6 +1014,9 @@ BOOL WINAPI InternetCloseHandle(HINTERNE > > return FALSE; > > } > > > > + if (lpwh->htype == WH_HHTTPREQ) > > + NETCON_close(&((LPWININETHTTPREQW)lpwh)->netConnection); > > + > > WININET_Release( lpwh ); > > WININET_FreeHandle( hInternet ); > > > > -- > > 1.4.1 > > > > > > Hi, > > This patch was sent 4 days ago and it hasn't gone in yet. Could anyone > give me some comments on it? Dan filed bug 10032 which is related to > this. While we shouldn't be using select() on high FDs for networking, > this patch closes the sockets that were open by http requests to avoid > getting to high FDs... > > Thanks, > -Nigel Hi, well looking over this very quickly right off the bat it does not seem correct to me. WININET_Release will call the close_connection method of the handle if it is defined, and for WH_HHTTPREQ this is HTTP_CloseConnection, which does call NETCON_Close along with sending all the proper status notifications, etc. So if in fact NETCON_Close is _not_ being called for some reason, you need to track down where involving those functions either why the proper one is not getting called (if that is the case) or if that function somehow needs to call NETCON_Close when it doesn't. Misha

Oct. 17, 2007

Re: [PATCH] wininet: Close sockets open in http requests

by Nigel Liang

On 10/13/07, Nigel Liang <ncliang(a)gmail.com> wrote: > Hi, > > Http requests open sockets and forget to close them. Left running over a long > period, the socket file descriptor starts getting large. Once it exceeds > FD_SETSIZE, the behavior becomes unpredictable and results in funcky crashes. > > -Nigel > > --- > dlls/wininet/internet.c | 3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/dlls/wininet/internet.c b/dlls/wininet/internet.c > index 0edca74..8e3a98e 100644 > --- a/dlls/wininet/internet.c > +++ b/dlls/wininet/internet.c > @@ -1014,6 +1014,9 @@ BOOL WINAPI InternetCloseHandle(HINTERNE > return FALSE; > } > > + if (lpwh->htype == WH_HHTTPREQ) > + NETCON_close(&((LPWININETHTTPREQW)lpwh)->netConnection); > + > WININET_Release( lpwh ); > WININET_FreeHandle( hInternet ); > > -- > 1.4.1 > > Hi, This patch was sent 4 days ago and it hasn't gone in yet. Could anyone give me some comments on it? Dan filed bug 10032 which is related to this. While we shouldn't be using select() on high FDs for networking, this patch closes the sockets that were open by http requests to avoid getting to high FDs... Thanks, -Nigel

Oct. 17, 2007