Does anyone know where a call to OLE2A is going to enter wine? Presumably OLE2A returning null means that the thread ran out of stack space?
Bill Medland
On Wed, May 02, 2007 at 03:32:59PM -0700, Bill Medland wrote:
Does anyone know where a call to OLE2A is going to enter wine? Presumably OLE2A returning null means that the thread ran out of stack space?
What is OLE2A? I do not see it mentioned anyewhere in the Wine source.
Any more debugging output?
Ciao, Marcus
On Thu, 2007-03-05 at 07:49 +0200, Marcus Meissner wrote:
On Wed, May 02, 2007 at 03:32:59PM -0700, Bill Medland wrote:
Does anyone know where a call to OLE2A is going to enter wine? Presumably OLE2A returning null means that the thread ran out of stack space?
What is OLE2A? I do not see it mentioned anyewhere in the Wine source.
Any more debugging output?
Ciao, Marcus
Hi Marcus, thanks for taking interest.
A little late now, I think. The problem is not where I thought it was.
OLE2A is a Microsoft macro used to convert e.g. a BSTR to a char *, allocating memory on the stack and calling one of the wide-to-narrow conversions.
Our program was behaving quite strangely, throwing an exception from some code that should not throw an exception.
I traced it down to some code that did an OLE2A on a BSTR, called strlen on the return and then passed the same narrow string to a function. The problem occurred when the OLE2A returned a null pointer. Due to an oversight I thought the BSTR was non-null and assumed that somehow the underlying alloca must be returning null (i.e. was detecting out-of- stack-space).
Now I discover that the BSTR itself was also NULL so that makes sense.
I presume what happens is all that magic that traps the segment violation on strlen(0) didn't quite handle whatever optimised code was being generated for our case.
However what I am also investigating is where the original NULL BSTR came from; possibly a defect in VariantChangeTypeEx.
Bill
On Thu, 2007-03-05 at 07:29 -0700, Bill Medland wrote:
On Thu, 2007-03-05 at 07:49 +0200, Marcus Meissner wrote:
On Wed, May 02, 2007 at 03:32:59PM -0700, Bill Medland wrote:
Does anyone know where a call to OLE2A is going to enter wine? Presumably OLE2A returning null means that the thread ran out of stack space?
What is OLE2A? I do not see it mentioned anyewhere in the Wine source.
Any more debugging output?
Ciao, Marcus
Hi Marcus, thanks for taking interest.
A little late now, I think. The problem is not where I thought it was.
OLE2A is a Microsoft macro used to convert e.g. a BSTR to a char *, allocating memory on the stack and calling one of the wide-to-narrow conversions.
Our program was behaving quite strangely, throwing an exception from some code that should not throw an exception.
I traced it down to some code that did an OLE2A on a BSTR, called strlen on the return and then passed the same narrow string to a function. The problem occurred when the OLE2A returned a null pointer. Due to an oversight I thought the BSTR was non-null and assumed that somehow the underlying alloca must be returning null (i.e. was detecting out-of- stack-space).
Now I discover that the BSTR itself was also NULL so that makes sense.
I presume what happens is all that magic that traps the segment violation on strlen(0) didn't quite handle whatever optimised code was being generated for our case.
However what I am also investigating is where the original NULL BSTR came from; possibly a defect in VariantChangeTypeEx.
Actually VariantChangeType was returning E_INVALIDPARAM and a VT_EMPTY and the caller wasn't checking the result.
However I think VariantChangeType was wrong in this case.
Bill
So.
1. Am I misunderstanding something about the tests these days?
(I am about to add two edge tests on SystemTimeToFileTime in time.c and GetDateFormatW in locale.c)
I go into dlls/kernel32/tests and make tests and it fails (change.c, locale.c)
Should that disconcert me?
2. How to fix the VarBstrFromDate?
VarBstrFromDate(-657434.0 (DATE_MIN), 0x409, 0x80000000, wherever) fails because VariantTimeToSystemTime successfully converts that to 1/1/100 but then VarBstrFromDate tries to format that using GetDateFormat, which is not feasible because the SystemTime is out of range.
Is there an existing low level routine that can handle the conversion for such a small date?
Bill
Bill Medland wrote:
On Thu, 2007-03-05 at 07:29 -0700, Bill Medland wrote:
On Thu, 2007-03-05 at 07:49 +0200, Marcus Meissner wrote:
On Wed, May 02, 2007 at 03:32:59PM -0700, Bill Medland wrote:
Does anyone know where a call to OLE2A is going to enter wine? Presumably OLE2A returning null means that the thread ran out of stack space?
What is OLE2A? I do not see it mentioned anyewhere in the Wine source.
Any more debugging output?
Ciao, Marcus
Hi Marcus, thanks for taking interest.
A little late now, I think. The problem is not where I thought it was.
OLE2A is a Microsoft macro used to convert e.g. a BSTR to a char *, allocating memory on the stack and calling one of the wide-to-narrow conversions.
Our program was behaving quite strangely, throwing an exception from some code that should not throw an exception.
I traced it down to some code that did an OLE2A on a BSTR, called strlen on the return and then passed the same narrow string to a function. The problem occurred when the OLE2A returned a null pointer. Due to an oversight I thought the BSTR was non-null and assumed that somehow the underlying alloca must be returning null (i.e. was detecting out-of- stack-space).
Now I discover that the BSTR itself was also NULL so that makes sense.
I presume what happens is all that magic that traps the segment violation on strlen(0) didn't quite handle whatever optimised code was being generated for our case.
However what I am also investigating is where the original NULL BSTR came from; possibly a defect in VariantChangeTypeEx.
Actually VariantChangeType was returning E_INVALIDPARAM and a VT_EMPTY and the caller wasn't checking the result.
However I think VariantChangeType was wrong in this case.
Bill
So.
- Am I misunderstanding something about the tests these days?
(I am about to add two edge tests on SystemTimeToFileTime in time.c and GetDateFormatW in locale.c)
I go into dlls/kernel32/tests and make tests and it fails (change.c, locale.c)
Did you try to run make test a second time? Sometimes that makes it go further.
Should that disconcert me?
Yes and no. The theory says that the tests should run on everybodies computer out of the box. The practice disagrees with this and afair only on Alexandre's computer all tests succeed. We should fix that and from time to time somebody tries to do it but it's no sexy work so that effort dies pretty soon. What i do is to run the tests on an origin Wine checkout and then on my modified tree and see if i get any additional failures/successes.
- How to fix the VarBstrFromDate?
VarBstrFromDate(-657434.0 (DATE_MIN), 0x409, 0x80000000, wherever) fails because VariantTimeToSystemTime successfully converts that to 1/1/100 but then VarBstrFromDate tries to format that using GetDateFormat, which is not feasible because the SystemTime is out of range.
Is there an existing low level routine that can handle the conversion for such a small date
Add a test for the VarBstrFromDate(-657434.0 ... call and see how Windows handles that. When you know the outcome you'll know how to fix it.
bye michael
On Fri, 2007-04-05 at 13:34 +0200, Michael Stefaniuc wrote:
Bill Medland wrote:
On Thu, 2007-03-05 at 07:29 -0700, Bill Medland wrote:
On Thu, 2007-03-05 at 07:49 +0200, Marcus Meissner wrote:
On Wed, May 02, 2007 at 03:32:59PM -0700, Bill Medland wrote:
Does anyone know where a call to OLE2A is going to enter wine? Presumably OLE2A returning null means that the thread ran out of stack space?
What is OLE2A? I do not see it mentioned anyewhere in the Wine source.
Any more debugging output?
Ciao, Marcus
Hi Marcus, thanks for taking interest.
A little late now, I think. The problem is not where I thought it was.
OLE2A is a Microsoft macro used to convert e.g. a BSTR to a char *, allocating memory on the stack and calling one of the wide-to-narrow conversions.
Our program was behaving quite strangely, throwing an exception from some code that should not throw an exception.
I traced it down to some code that did an OLE2A on a BSTR, called strlen on the return and then passed the same narrow string to a function. The problem occurred when the OLE2A returned a null pointer. Due to an oversight I thought the BSTR was non-null and assumed that somehow the underlying alloca must be returning null (i.e. was detecting out-of- stack-space).
Now I discover that the BSTR itself was also NULL so that makes sense.
I presume what happens is all that magic that traps the segment violation on strlen(0) didn't quite handle whatever optimised code was being generated for our case.
However what I am also investigating is where the original NULL BSTR came from; possibly a defect in VariantChangeTypeEx.
Actually VariantChangeType was returning E_INVALIDPARAM and a VT_EMPTY and the caller wasn't checking the result.
However I think VariantChangeType was wrong in this case.
Bill
So.
- Am I misunderstanding something about the tests these days?
(I am about to add two edge tests on SystemTimeToFileTime in time.c and GetDateFormatW in locale.c)
I go into dlls/kernel32/tests and make tests and it fails (change.c, locale.c)
Did you try to run make test a second time? Sometimes that makes it go further.
Yes. Even make clean.
Should that disconcert me?
Yes and no. The theory says that the tests should run on everybodies computer out of the box. The practice disagrees with this and afair only on Alexandre's computer all tests succeed. We should fix that and from time to time somebody tries to do it but it's no sexy work so that effort dies pretty soon. What i do is to run the tests on an origin Wine checkout and then on my modified tree and see if i get any additional failures/successes.
That's what I figured.
- How to fix the VarBstrFromDate?
VarBstrFromDate(-657434.0 (DATE_MIN), 0x409, 0x80000000, wherever) fails because VariantTimeToSystemTime successfully converts that to 1/1/100 but then VarBstrFromDate tries to format that using GetDateFormat, which is not feasible because the SystemTime is out of range.
Is there an existing low level routine that can handle the conversion for such a small date
Add a test for the VarBstrFromDate(-657434.0 ... call and see how Windows handles that. When you know the outcome you'll know how to fix it.
Invalid assumption. Knowing the problem doesn't automatically give us the answer.
I know the outcome; for the flags and lcid I was using it is 1/1/100 (n.b. 3 digit year). That is in the patch I submitted yesterday. What I am after is the most efficient way to implement the fix while maintaining compatibility and not messing up the code base.
How does this sound?
Add an argument to NLS_GetDateTimeFormatW/A to flag whether the systemtime should be constrained to >= 1/1/1601 and add a "wine" routine that calls it with that flag set to NO. and use that. In that way we can keep the formatting code in one place and still get the extended date range that oleaut32 needs.
bye michael
Bill
-
Bill Medland -
Marcus Meissner -
Michael Stefaniuc