yang686526

mac ppc crash when calling exsystemservices::formatmessage()
mac ppc crash when calling exsystemservices::formatmessage()
folks,
i am seeing a crash in my code that is called by oddbhostappservices here:
odstring exsystemservices::formatmessage(unsigned int code, va_list *arglist)
when it calls odstring.formatv(). the crash is in wcslen() which is called by getmaxformatstrlen().
the contents of |arglist| on an intel mac point to an empty odstring, which has the 4-bytes unicode characters "(null)". on the mac ppc (tiger and leopard), the contents of |arglist| are garbled.
my question is, where does the unicode string "(null)" come from? is this in some support code that i need to be responsible for? or is it internal to odstring? any ideas as to why the 4-byte unicode string would be garbled on a big-endian computer and not on the little-endian?
thanks!
- dave.
one point of clarification: on the intel platform, |arglist| points to an odstring containing a pointer to a unicode string which has 4 '0' bytes initially. this eventually gets turned into "(null)" by odstring::formatv(). on the ppc platform, this causes wcslen() to just crash.
could you please provide a few lines of code to be inserted into some of our samples (e.g. odreadex), to reproduce the problem?
vladimir
sure. the code is at the end of this message. the crash occurs when calling msg.formatv(message[code], *arglist) - i looked at message[code] and it is a valid 4-byte unicode string:
code page conversion is impossible because conversion table for "%ls" is missing.
i looked at |arglist| (not sure how to do this correctly, though), and i get these results on intel:
(gdb) p *(odchar **)arglist
$4 = (odchar *) 0xbfffdc4c
(gdb) x/64b $4
0xbfffdc4c: 0x00 0x00 0x00 0x00 0x30 0xf0 0x54 0x3c
0xbfffdc54: 0xa0 0x9f 0x57 0x3c 0x01 0x00 0x00 0x00
0xbfffdc5c: 0x00 0xf0 0x7a 0x10 0xb5 0x45 0xd8 0x00
0xbfffdc64: 0x19 0x00 0x00 0x00 0x02 0xab 0x5d 0x0f
0xbfffdc6c: 0x00 0xbe 0x26 0x11 0x94 0x76 0x54 0x3c
0xbfffdc74: 0x19 0x00 0x00 0x00 0x98 0xdc 0xff 0xbf
0xbfffdc7c: 0x02 0x00 0x00 0x00 0x80 0xf6 0x54 0x3c
0xbfffdc84: 0x18 0xdd 0x0b 0xf1 0xa8 0xdc 0xff 0xbf
but, on ppc i get these results:
(gdb) p *(odchar **)arglist
$14 = (odchar *) 0xbfffd274
(gdb) x/64b $14
0xbfffd274: 0xff 0xff 0xff 0xff 0xbf 0xff 0xce 0x70
0xbfffd27c: 0x00 0x00 0x00 0x00 0xff 0xff 0xff 0xff
0xbfffd284: 0x00 0x00 0x00 0x02 0x0f 0xfd 0xf3 0x20
0xbfffd28c: 0x00 0x00 0x26 0xc2 0x10 0xd8 0xa6 0xbc
0xbfffd294: 0xbf 0xff 0xd4 0x18 0x3c 0xa1 0x34 0x30
0xbfffd29c: 0x00 0x00 0x00 0x00 0x3c 0xa1 0x28 0x10
0xbfffd2a4: 0x00 0x00 0x00 0x27 0x3c 0xa1 0x25 0xf0
0xbfffd2ac: 0x3c 0xa1 0x2b 0x50 0x10 0x03 0x4c 0xf4
note that the first bytes on ppc are 0xff, while on intel they are all 0x00. this might explain the crash in wcslen() on the ppc.
thanks for helping!
- dave.
code follows:
odstring exsystemservices::formatmessage(unsigned int code, va_list* arglist)
{
#ifdef _native_wchar_t_defined
static const wchar_t* message[] =
#else
static const odchar* message[] =
#endif
{
#define od_error_def(cod, desc) desc,
#include "errordefs.h"
#undef od_error_def
#define od_message_def(cod, desc) desc,
#include "messagedefs.h"
#undef od_message_def
dd_t("")// dummylastmassage
};
odstring msg;
if (code >= siddummylastmassage)
{
msg.format(dd_t("unknown message (code: %d)"), code);
return msg;
}
if (arglist)
{
msg.formatv(message[code], *arglist);
}
else msg = message[code];
return msg;
}
the code you quoted is unmodified version of exsystemservices::formatmessage
do you mean that i can just run any example on mac ppc, that uses formatmessage, and it will crash?
(i'll try)
vladimir
yes, it should crash when it tries to call formatv when you have a format string that specifies %ls, and a parameter that points to a null string. on the intel box, the |arglist| parameter points to all nul bytes (0x00); but on the ppc, it points to 0xff bytes. i have been trying to figure out where the 0xff bytes come from, but i am not getting very far.
in debugging this further, it appears that oddbdatabase::readfile(odstreambuf, odstring) is calling formatmessage with an improperly cast odstring as a parameter, right after it decides that the codepage is not supported. i imagine the call sequence goes something like:
odstring codepage; // initialized to the kempty string.
if (codepageisnotsupported) {
oddbhostappservices::formatmessage(475, &codepage);
} else {
// continue processing with the codepage.
}
from the debugger, it looks like |codepage| in above example is not converted to an odchar * before the call to formatmessage() is made - i say this because odstring::c_str() is never called in between the time |codepage| is constructed and when it is passed into formatmessage(). a pointer to the odstringdata is passed into the lower layers, and since |codepage| is an empty string, you dereference the -1 refcount instead of the string buffer.
let me know if this sounds right.
thanks!
- dave.
no, there is no such a code. it would crash on 32 bit platform also.
c_str() is an inline function, and breakpoints may not work there even in debug version (depending on the compiler).
unfortunately, mac projects are currently broken, and i'm unable to debug on mac. the projects should be fixed in a few days, then i'll investigate the problem.
which dd version do you use?
what is the call stack at the point of crash?
vladimir
our dd version is 2.2. we cannot yet upgrade to 2.6 because we are very close to release and the upgrade would cause too large an instability. once we get out the door, i will look at upgrading to 2.6.
in the trace below, i was trying to export to an acad format that uses codepages instead of unicode (acad 2000). wcslen() is trying to dereference 0xffffffff in order to get a string length:
bt
#0 0x94b761a6 in wcslen ()
#1 0x0f590dbe in getmaxformatstrlen ()
#2 0x0f591d8c in odstring::formatv ()
#3 0x3a4385cd in exsystemservices::formatmessage (this=0xbfffe450, code=475, arglist=0xbfffbf0c) at /myapp/common/dwgdirect/exsystemservices.cpp:285
#4 0x0f597103 in oddbhostappservices::formatmessage ()
#5 0x0eeb2a00 in oddbdatabase::writefile ()
#6 0x3a46a56f in oddbdatabase::writefile (this=0x3d51aae0, filename=@0xbfffe3b4, filetype=kdwg, fileversion=kdhl_1015, savethumbnailimage=true, dxfprecision=16) at ../../../../../../third_party/include/dwgdirect/dbdatabase.h:784
#7 0x3a43780a in cacadexporter::closefile (this=0xbfffe428) at /myapp/common/acadexporter.cpp:380
#8 0x3a42154c in -[exportmodeldwg export:to:usingformatptionsset:callback:] (self=0x267f5d70, _cmd=0x5fd888, docinterface=0x3d41ac0c, filename=0x3d367080, format=6, optionswereset=0 '\0', progress=0x3d416620) at /myapp/common/mac/exportmodeldwg.mm:245
#9 0x00361b59 in -[exportercontroller(private) doexport:] (self=0x3d337a20, _cmd=0x5fdcd4, dummy=0x0) at /myapp/common/exportercontroller.mm:918
#10 0x90fa564d in __nsfiredelayedperform ()
#11 0x918d4b45 in cfrunlooprunspecific ()
#12 0x918d4cf8 in cfrunloopruninmode ()
#13 0x90744480 in runcurrenteventloopinmode ()
#14 0x90744299 in receivenexteventcommon ()
#15 0x9074410d in blockuntilnexteventmatchinglistinmode ()
#16 0x940fa3ed in _dpsnextevent ()
#17 0x940f9ca0 in -[nsapplication nexteventmatchingmask:untildate:inmode:dequeue:] ()
#18 0x940f2cdb in -[nsapplication run] ()
#19 0x940bff14 in nsapplicationmain ()
#20 0x0000b6a5 in main (argc=1, argv=0xbffff5f8) at /users/dspringer/source/sketchup/googleclient/sketchup/source/sketchup/macapp/main.m:18
#21 0x00002b0a in _start ()
#22 0x00002a31 in start ()
(gdb)
i see.
this bug was fixed a year ago - there was indeed an invalid argument.
vladimir
thanks, vldimir! it looks like we need to upgrade to the latest 2.6 libraries.
are there any major api changes from 2.2 to 2.6 that i need to watch out for?
thanks for helping out on this,
- dave.
i don't remember any major changes.
you may read release notes though:
vladimir