Re: urlmon:sec_mgr failure on XP
Hi Francois, On Sat, Sep 10, 2011 at 6:33 AM, Francois Gouget fgou...@free.fr wrote: This test now fails on my Widnows XP VMs that have IE = 7 with 'All zones reset to default level': http://test.winehq.org/data/3b40c03a8f0e3dcbb236d59125b115b2501086f8/xp_fg-winxp-latest/urlmon:sec_mgr.html sec_mgr.c:1695: Test failed: Expected zone 3, but got 1 for 'file/testing/test.test' I wasn't able to reproduce this problem on my Windows XP VM. I was, however, able to reproduce this problem using Windows 7. So I'm hoping that you can fix the test. The easiest fix would be to remove the 'file/testing/test.test' check. An alternative would be to check what the settings are and adjust the expected result or skip the test. But it seems like this would be much more complex. The test in question isn't really relevant with showing how the function itself should work, so removing it will be fine (I'll be sending a patch shortly removing it). Thanks for pointing this issue out. -- Thomas Mullaly thomas.mull...@gmail.com
Re: [1/4] urlmon: Use CoTaskMemFree instead of HeapFree for memory allocated with CoTaskMemAlloc
Hi Jacek, On Mon, Sep 5, 2011 at 3:33 AM, Jacek Caban ja...@codeweavers.com wrote: AFAICS secur_url wasn't allocated with CoTaskMemAlloc until this patch. Why are you changing it? map_url_to_zone gets secur_url allocated in one of two ways. The first way is through CoInternetGetSecurityUrl, which allocates the resulting URL with CoTaskMemAlloc. The second way is if CoInternetGetSecurityUrl fails, in which case it was allocating with HeapAlloc. Since we can't change how CoInternetGetSecurityUrl allocates memory, I switched everything to use the CoTaskMem* functions, so that we don't mix CoTaskMemAlloc functions with HeapFree functions. -- Thomas Mullaly thomas.mull...@gmail.com
Re: Use of uninitialized variable in combine_uri()
Hi Gerald,
On Tue, Nov 2, 2010 at 6:51 PM, Gerald Pfeifer ger...@pfeifer.com wrote:
Hi Thomas,
the following change of yours
commit bced2e21dbc548ef9d41e3ff11384d7ad964c929
Author: Thomas Mullaly thomas.mull...@gmail.com
Date: Sat Oct 9 11:02:17 2010 -0400
urlmon: Implemented base case for CoInternetCombineIUri.
introduces a new warning, use of uninitialized variable in the line
marked HERE below.
+static HRESULT combine_uri(Uri *base, Uri *relative, DWORD flags, IUri
**result
+ Uri *ret;
+ HRESULT hr;
+ parse_data data;
+
+ /* Base case is when the relative Uri has a scheme name,
+ * if it does, then 'result' will contain the same data
+ * as the relative Uri.
+ */
+ if(relative-scheme_start -1) {
+ DWORD create_flags = 0;
+
+ memset(data, 0, sizeof(parse_data));
+
+ data.uri = SysAllocString(relative-raw_uri);
+ if(!data.uri) {
+ IUri_Release(URI(ret)); == HERE
+ *result = NULL;
+ return E_OUTOFMEMORY;
+ }
From all I can tell this is a legitimate warning, that is, the code
really invokes undefined behavior. Would you mind having a look?
Gerald
Whoa! Good catch, I'll submit a new patch set here in a few minutes fixing that.
Thank you for the heads up.
--
Thomas Mullaly
thomas.mull...@gmail.com
Re: [2/7] urlmon/tests: Removed no longer needed todo_wine's
Hi Paul, On Thu, Sep 9, 2010 at 2:19 AM, Paul Vriens paul.vriens.w...@gmail.comwrote: todo_wine's that succeed are marked as failures so that means these are not fixed on (at least) AJ's box as otherwise previous patches would have been rejected. The reason they didn't show up as test succeeded failures on wine is because they weren't getting executed on wine. This is because IUriBuilder_GetIUri wasn't implemented which means it would skip those tests on wine. I implemented GetIUri in patch 5/7 of this set which would have caused a lot of test succeeded failures until the todo's were removed. So I decided (since removing the todo's just by themselves resulted in a lot of changes) to keep this patch separate from the 5/7 patch. Of course, if it's preferred, I can always merge the changes into patch 5/7 and resubmit this set. -- Thomas Mullaly thomas.mull...@gmail.com
Re: The Test Bot seems to be having issues
On Fri, Aug 20, 2010 at 4:44 AM, GOUJON Alexandre ale.gou...@gmail.comwrote: It's Grep Geldorp but wine-devel is a good place too. Thanks, hopefully he notices the thread. There are some div and /div in your patch. Anyway, the bot applied your patch successfully and began to run some of your tests. Hmm... All my patches (coming through wine-patches) seem to end up with those div tags in them, but, they've never caused problems. Now, the only thing to do is waiting... At this point I would be surprised if the Test bot started randomly working without any assistance. The job has been in the running state for 24+ hours already, without any progress being made. -- Thomas Mullaly thomas.mull...@gmail.com
The Test Bot seems to be having issues
Hi all, First off, I'm not sure who should be contacted about this, but, it appears that the test bot has got itself stuck while trying to run tests on a patch submitted last night. The job in question is here [1], it's been over 12 hours since any progress has been made on it and no other submissions have run since then. Also, the Windows 98SE has been reverting this whole time, so I'm not sure if this is the culprit or not. I also hate to admit that the job in question is from one of my patches I sent in last night (although I'm pretty sure it doesn't have anything to do with the quality of the code in the patch ;-) ). Anyways, I'm hoping that somebody in charge of the test bot might be able to fix the traffic jam it's causing. [1] https://testbot.winehq.org/JobDetails.pl?Key=4570 https://testbot.winehq.org/JobDetails.pl?Key=4570 -- Thomas Mullaly thomas.mull...@gmail.com
Re: [3/5] urlmon: Implemented canonicalization for ports in URIs
On Wed, Jul 28, 2010 at 8:14 AM, Alexandre Julliard julli...@winehq.orgwrote: Thomas Mullaly thomas.mull...@gmail.com writes: --- dlls/urlmon/uri.c | 88 +++- 1 files changed, 86 insertions(+), 2 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M urlmon.dll -T ../../.. -p urlmon_test.exe.so uri.c touch uri.ok uri.c:2788: Test failed: Error: Expected a length of 0 but got -2 on uri_tests[13].str_props[6]. make: *** [uri.ok] Error 1 Hmm... that's weird. The patch didn't change any of the test cases nor did it even change any of the implementations that it's now failing on. I would like to ask if you could ignore the whole patch set until I figure out what's going on, since the bug might have been introduced earlier in the set. Thanks. -- Thomas Mullaly thomas.mull...@gmail.com
Re: [6/6] urlmon/tests: Added some more test URIs (resend)
On Wed, Jul 28, 2010 at 8:09 PM, Marvin test...@testbot.winehq.org wrote: === WXPPROSP3 (32 bit uri) === uri.c:2169: Test failed: Expected http://google.com:00035 but got L http://google.com:35; on uri_tests[60].str_props[2]. uri.c:2400: Test failed: Error: Expected http://google.com:00035 but got Lhttp://google.com:35; on uri_test[60]. uri.c:2856: Test failed: Error: Expected a length of 23 but got 20 on uri_tests[60].str_props[2]. === WVISTAADM (32 bit uri) === uri.c:2169: Test failed: Expected http://google.com:00035 but got L http://google.com:35; on uri_tests[60].str_props[2]. uri.c:2400: Test failed: Error: Expected http://google.com:00035 but got Lhttp://google.com:35; on uri_test[60]. uri.c:2856: Test failed: Error: Expected a length of 23 but got 20 on uri_tests[60].str_props[2]. === W2K8SE (32 bit uri) === uri.c:2169: Test failed: Expected http://google.com:00035 but got L http://google.com:35; on uri_tests[60].str_props[2]. uri.c:2400: Test failed: Error: Expected http://google.com:00035 but got Lhttp://google.com:35; on uri_test[60]. uri.c:2856: Test failed: Error: Expected a length of 23 but got 20 on uri_tests[60].str_props[2]. There seems to subtle differences between the implementations of CreateUri, since these tests only failed on machines with IE7 installed and passed on the machines with IE8 installed... -- Thomas Mullaly thomas.mull...@gmail.com
Re: urlmon: CreateUri should return E_INVALIDARG for NULL args.
On Thu, May 13, 2010 at 3:41 AM, Paul Vriens paul.vriens.w...@gmail.comwrote: I don't think these comments are needed as the same is shown in the tests below (I was actually triggered by the wrong spelling of 'receives' btw). Whoops. I always manage to misspell receive somehow... I'll submit a new patch here shortly. -- Thomas Mullaly thomas.mull...@gmail.com
Re: [GSoC] IUri Implementations
Hi Jacek, Test should be integrated with Wine tests. See dlls/shlwapi/tests/url.c and dlls/wininet/tests/url.c for an idea of how it should be done. Thank you, shlwapi's url test was very helpful and has given me some good ideas for testing. If you have specific questions, feel free to ask here. Proposal itself should be posted to gsoc app. It's capable of editing proposals and getting feedback. Here's the link to my proposal http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/thomas_mullaly/t127066435448 I would greatly appreciate it if anybody would check it out and leave feedback/suggestions for it.
Re: [GSoC] IUri Implementations
In general, the idea looks right, that's how it probably should be implemented. This is an implementation detail through. The bigger and more important problem is URI parsing and canonicalization. That's where most of work needs to be done. In this case tests will be also very important. You don't know how it should work until you have a test. The first step would be to write a test infrastructure some tests (adding new test shouldn't be harder than filling a table with more data). Once it's done, you'll be able to decide on best way to implement parser and IUri interface. The project should result in many tests and good support for at least more useful flags and IUri functions. Hi Jacek, Sorry for my delayed response. Thank you for your suggestions. For the testing infrastructure, I was thinking about writing a few Windows programs that use Microsoft's IUri implementation to generate the results that my testing infrastructure would use to make sure my implementation is working correctly. Is this the right approach or would you recommend doing it another way? Also, I have finished a rough draft of my proposal and I was wondering if it would appropriate to post to it to the mailing list in order to receive feedback from you and others.
[GSoC] IUri Implementations
Hi, my name is Thomas Mullaly and I am a undergraduate in the Computer Science department at Kent State University and I would very much like to participate in this years GSoC. I saw under your project ideas page that the IUri API still needs implemented and I thought that this would be a good project for me, but, before I submit a proposal on it I have a few questions about the project itself. Firstly, on the project page it says that the main goal is to have the IUri interface and CreateUri function implemented, but, on MSDN they also have functions and interfaces for creating/manipulating IUriBuilder's and I was wondering if these were also part of the project goals. If not can they be or would this be to ambitious to have finished by the end of the summer. Secondly (more of a design question), I see that the Uri structure and functions are already stubbed out in the dlls/urlmon/uri.c file and I was thinking for my implementation I would add another BSTR* member to the Uri struct, which will point to the encoded version of the URI (which will be generated during the CreateUri() call). Since most of the functions that interact with the IUri return components of the URI (e.g. scheme, host, query, etc.) I was thinking about adding more data members to the Uri struct which store the location in the encoded Uri string where each component exists (or -1 if it does not exist) and by doing this the runtimes of the IUri functions will be reduced since the function will already know where to look inside the encoded string for the component it needs. A drawback to this design is that each Uri struct will be bloated with a decent amount of ints which may or may not be used depending on the type of the URI that the IUri represents. The second approach I was thinking of is to not store any locations inside the Uri struct and to compute them on the fly every time the IUri is queried for one of its components, this would result in a smaller memory footprint of the Uri structure but will increase the runtimes of all the functions that access the URI. I was wondering if anyone might have suggestions for which way they think might be better. Any input will be greatly appreciated! -Thomas Mullaly
Re: [GSoC] IUri Implementations
You could use dynamic array for that or a list with a Uri_PROPERTY
value as a key for example and a data as an offset and length. Another
way is to compute each property offset only when it's requested and
store it. An obvious bad case for that is a long uri. So probably one
pass property computation while building IUri instance is not bad.
I like the idea of making a lightweight data structure which stores the
offset and length for each component property. I'd imagine it would look
something like this:
typedef struct {
DWORD offset;
DWORD length;
} UriComponent;
Although it becomes a little more tricky on how to store the
UriComponents, but, I have a few ideas if anyone has any suggestions.
I do like the idea of using an array inside the Uri struct to store the
UriComponents but not all of the values in the Uri_PROPERTY enum
actually mean anything (at least thats what I have gathered from reading
the MSDN docs), like the Uri_PROPERTY_STRING_START and the
Uri_PROPERTY_STRING_LAST are just there to say all the enum values
between = START and = LAST correspond the string components of the URI.
So I'm thinking the Uri struct should have a constant size array of
UriComponents of length Uri_PROPERTY_STRING_LAST (which would be 15..
correct me if I'm wrong).
So it would look something like...
typedef struct {
/** The other stuff */
BSTR *uri;
UriComponents components[15];
} Uri;
and then for the GetPropertyBSTR(BSTR *component, Uri_PROPERTY prop)
function you could just have something like.
if(prop = Uri_PROPERTY_START prop = Uri_PROPERTY_LAST) {
UriComponent comp;
comp = uri-components[prop];
/** Parse the component out */
}
And that should get you the necessary offsets and lengths for the
component you need.
I also like the idea suggested before using a one-pass solution to find
everything when the Uri is constructed.
Thank you for the quick responses and suggestions, I hope to have a
proposal ready in the next few days.
