Hello Viktor,
On Apr 27, 2010, at 6:39 AM, Viktor Szakáts wrote:
> Hi All,
>
> Lately I mentioned having "random" GPFs with my live apps
> since changing to Harbour r14336. I also mentioned they are
> gone. This turned out not to be true, they are still present.
>
> I have about 100KB of local .c code, which has been pretty
> much static with only one benign change done in parallel with
> Harbour upgrade, plus USHORT -> HB_USHORT type migration.
>
> The app uses GTWVT and it's built with mingw (tdm latest),
> just as before.
>
> GPF happens at random places, even in kernel, so it must
> be some sort of memory corruption. Users report that many
> times the problem happens when pasting into the application.
> They experience that the app just closes, and I can't see
> a GPF logged for all of these occasions. GPF can happen even
> after short period of time spent in the application, with
> little amount of activity.
>
> It looks like something is lurking inside Harbour code,
> and just by hunch one of my suspects is UNICODE mode build,
> in relation with copy/paste, keyboard handling, or run
> operations.
This is a very long shoot.
I had an GPF problem with an GUI app; this app is meant to run
mainly on Windows and using UNICODE,
The users reported a random GPF with different intervals of
running app time, places and so. I was unable to reproduce the
problem under Windows so I setup an Linux workstation meant
to run the Linux version of the app, and builded in debug mode
( at C/C++ level ) that's when the GPF showed in gdb.
The problem was originated by a wrong parameter call to the
'hb_cdpUTF8StringLength' function, and the program
sometimes stopped when executing that function and sometimes
in some other different places, so the conclusion was that it was
corrupting memory.
Bellow is the code snippet when the above funct is used:
<c++ code>
wxString wxh_CTowxString( const char * szStr, bool convOEM )
{
#ifdef _UNICODE
const wxMBConv& mbConv = wxConvUTF8;
if( convOEM && szStr )
{
ULONG ulStrLen = strlen( szStr );
PHB_CODEPAGE pcp = hb_vmCDP();
if( ulStrLen > 0 && pcp )
{
wxString wxStr;
ULONG ulUTF8Len = hb_cdpUTF8StringLength( szStr, ulStrLen );
char *strUTF8 = (char *) hb_xgrab( ulUTF8Len + 1 );
hb_cdpStrToUTF8( pcp, false, szStr, ulStrLen, (char *) strUTF8,
ulUTF8Len + 1 );
wxStr = wxString( strUTF8, mbConv );
hb_xfree( strUTF8 );
return wxStr;
}
}
#else
</c++ code>
The wrong call was due to calling the function with an NIL
as parameter without checking for a valid CHAR param
passed:
<c++ code>
wxString wxh_parc( int param )
{
return wxh_CTowxString( hb_parc( param ), TRUE );
}
</c++ code>
The fix was to check for a valid parameter ( not NIL ) being
send to the above function. In fact this problem would be solved
at PRG level but an protection at C++ level was also added too.
>
>
> Any idea what to check, or where the problem can be?
> I've reviewed some Harbour code, but could not yet spot
> anything.
HTH
best regards,
Teo
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
