I've just committed a fix for Combobox.xs (GetString) and Listbox.xs
(GetString) - both weren't allocating enough space for
Do you think this problem would have been more likely to show up on Windows
XP than on Windows 2000? I have an application that seems quite robust on
Windows 2000, but it has had a mysterious crash on Windows XP. Combobox
manipulations have been suspected from the stack traces, but I've never
been able to track it down.
If you are using Perl 5.8.x, then yes this could be the cause of your
problem. I'm using XP.
I'll give you an example of how this issue was effecting me, to show you how
odd the effects could be. My application ran fine under 5.6.1, but as soon
as it was running under 5.8.7, I was getting the strangest crashes. At
first, I suspected my own XS modules, so I spent several hours separating
the GUI from the logic of the application. Still crashes. ARH! I tracked it
down to a single perl substr - comment out the substr - no crash - put a
print statement before the substr - no crash. The stack trace showed that
perl was actually crashing at the substr, but it was crashing via free, and
finally going belly up in one of the core MS dll's. Clearly, this was a
memory issue, but I didn't know where.
Stripping down the application even more, I came across a different crash
where passing 'undef' to the tree insert item caused a crash. In the logic
of my app, I was updating various drop downs as items are added to this
tree. This turned out to be the key, as once I got around the tree crash, I
was getting the first stack traces where the crash was occurring in
SendMessage (Combobox.xs, just after the problem safemalloc). It was still
occurring at random times, but at least I has some sort of 'provable' case.
The issue is simply that we were overflowing the buffer by 1 character - in
this case by writing zero ("\0"). Now, in pervious versions of perl (or
indeed, depending on the underlying OS) the actual pointer returned by
safemalloc might be larger than the buffer requested. In these cases, there
would never be an issue. Even if the buffer returned by safemalloc was
exactly the requested size, it might not cause a crash or even a problem,
depending on what the underlying application is doing. In short, almost
random crashes!
Testing will take a few days, because I need to ship a new version to my
client that encounters the problem regularly... I can't produce it on
demand like she can, although I have produced it a few times on XP, but
never on 2K.
I would be interested to hear if this problem goes away. I still suspect
there are still a few problems with Win32-GUI and 5.8.x.
All solutions aren't Unicode aware, and going forward it's probably a good
idea to create a function/macro to handle the allocation of strings.
Yeah, it'd be nice to make Win32::GUI more Unicode aware. That's something
that I'm really interested in, and would be willing to help figure out and
work on, although to date I've not had much success in the figuring out
part (Rob has helped me get enough Unicode into one application to make me
happy, and that is my highest priority app for the present, to get that
working more completely...)
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/commctls/comboboxes/comboboxreference/comboboxmessages/cb_getlbtextlen.asp
Have a quick look at the above link. Basically, in all the cases where we
are using safemalloc to create a buffer large enough to hold a string, we're
using a MS function which returns the number of characters in the item.
Instead of assuming bytes, we would assume Unicode and the resulting buffer
would always be large enough. We really should create a helper function that
allocates enough space and use that instead of manually doing malloc.
Something like:
LPTSTR safemallocstring(int size) {
size++; #add one to ensure we have enough space for the terminating char
return (LPCTSTR) safemalloc (size*2);
}
Cheers,
jez.
