WoW crashes in 'wine_cp_mbstowcs' under certain circumstances.
These circumstances being if it tries to load an invalid lua file, more specifically a lua file which contains the invalid lua string (not character!) "\342\200\260". I don't know what this function does and there isn't a TRACE() in that function, so could someone please review if the function is implemented correctly (wrt the above char sequence) or give me more informations about the arguments so I could add a TRACE() to see what WoW passes to it? thanks tom
Hi, I think it trys to map the charector to the built-in ctable charector based on the locale. This function belongs to libwineunicode, ask Alexander for more info. Thanks and regards, Vijay On 4/17/06, Tomas Carnecky <tom(a)dbservice.com> wrote:
These circumstances being if it tries to load an invalid lua file, more specifically a lua file which contains the invalid lua string (not character!) "\342\200\260".
I don't know what this function does and there isn't a TRACE() in that function, so could someone please review if the function is implemented correctly (wrt the above char sequence) or give me more informations about the arguments so I could add a TRACE() to see what WoW passes to it?
thanks tom
Wine doesn't crash in this function, sorry, it's a bug in pf_vsnprintf() which causes snprintf() to write beyond the end of the buffer. I've attached a patch that fixes it for me, but it's probably better not to create such large buffers on the stack. Anyone with a better fix? tom
On 4/17/06, Tomas Carnecky <tom(a)dbservice.com> wrote:
Wine doesn't crash in this function, sorry, it's a bug in pf_vsnprintf() which causes snprintf() to write beyond the end of the buffer.
I've attached a patch that fixes it for me, but it's probably better not to create such large buffers on the stack. Anyone with a better fix?
tom
I think the patch breaks printing fields larger than 400. I think the existing code should have been able to handle very large fields by allocating the memory to do it. I think more investigation is needed. Jesse
Jesse Allen wrote:
On 4/17/06, Tomas Carnecky <tom(a)dbservice.com> wrote:
Wine doesn't crash in this function, sorry, it's a bug in pf_vsnprintf() which causes snprintf() to write beyond the end of the buffer.
I've attached a patch that fixes it for me, but it's probably better not to create such large buffers on the stack. Anyone with a better fix?
I think the patch breaks printing fields larger than 400. I think the existing code should have been able to handle very large fields by allocating the memory to do it. I think more investigation is needed.
I thought that, too, but 'flags.FieldLength' was always zero, so the function always used the 40-character buffer. tom
On 4/17/06, Tomas Carnecky <tom(a)dbservice.com> wrote:
Jesse Allen wrote:
On 4/17/06, Tomas Carnecky <tom(a)dbservice.com> wrote:
Wine doesn't crash in this function, sorry, it's a bug in pf_vsnprintf() which causes snprintf() to write beyond the end of the buffer.
I've attached a patch that fixes it for me, but it's probably better not to create such large buffers on the stack. Anyone with a better fix?
I think the patch breaks printing fields larger than 400. I think the existing code should have been able to handle very large fields by allocating the memory to do it. I think more investigation is needed.
I thought that, too, but 'flags.FieldLength' was always zero, so the function always used the 40-character buffer.
tom
In the case that it is specified greater than 400, it will break.
Jesse Allen wrote:
On 4/17/06, Tomas Carnecky <tom(a)dbservice.com> wrote:
Jesse Allen wrote:
On 4/17/06, Tomas Carnecky <tom(a)dbservice.com> wrote:
Wine doesn't crash in this function, sorry, it's a bug in pf_vsnprintf() which causes snprintf() to write beyond the end of the buffer.
I've attached a patch that fixes it for me, but it's probably better not to create such large buffers on the stack. Anyone with a better fix?
I think the patch breaks printing fields larger than 400. I think the existing code should have been able to handle very large fields by allocating the memory to do it. I think more investigation is needed.
I thought that, too, but 'flags.FieldLength' was always zero, so the function always used the 40-character buffer.
In the case that it is specified greater than 400, it will break.
What makes you think so? Sure the string buffer in the msvcrt test application isn't big enought to hold a 500 character string, but when I increase it it works fine. tom
On 4/17/06, Jesse Allen <the3dfxdude(a)gmail.com> wrote:
On 4/17/06, Tomas Carnecky <tom(a)dbservice.com> wrote:
Jesse Allen wrote:
On 4/17/06, Tomas Carnecky <tom(a)dbservice.com> wrote:
Wine doesn't crash in this function, sorry, it's a bug in pf_vsnprintf() which causes snprintf() to write beyond the end of the buffer.
I've attached a patch that fixes it for me, but it's probably better not to create such large buffers on the stack. Anyone with a better fix?
OK, I can kind of see a problem. If we converted this number on our own, we would set the field size to the number of printable characters before the final ouptut. But since we can't even look at the size at all, we rely on 40 because nothing is hardcoded into the format string. We will obviously overflow when we have more significant digits than 40 and no field size specified. But I also found something wrong with your test. Libc seems to remember far more digits and msvcrt rounds. So we also have a portability issue I think. The real solution is doing our own float conversions, but we can avoid the crash in the meantime by just making number larger; the output will still not be correct. Jesse
On 4/17/06, Tomas Carnecky <tom(a)dbservice.com> wrote:
Wine doesn't crash in this function, sorry, it's a bug in pf_vsnprintf() which causes snprintf() to write beyond the end of the buffer.
I've attached a patch that fixes it for me, but it's probably better not to create such large buffers on the stack. Anyone with a better fix?
tom
Basically your making number big enough to hold the output. You don't need to keep track of the max size. If it got truncated, it would be wrong anyway and the program may crash in a less obvious way. I'd say do this: Find out the minimum required size for number to make WoW not crash, and round up to the nearest 10's. Like your test required 91, make number 100. Hopefully we only need to do this once, and looking at the code, I'm sure that windows has a limitation like this somewhere too. Jesse
participants (3)
-
Jesse Allen -
Tomas Carnecky -
Vijay Kiran Kamuju