Hi Teo and All,
Thank you for your input. My code doesn't use any UTF8
calls, nor does it make any direct OS calls, or 3rd
party lib calls, it's pretty simple stuff, with extend/item
and GT API calls, only few .c level string manipulation,
and it has been checked using valgrind, too. It's not
very high suspect. (though I'd be happiest with zero line
of local .c code). I also use hbwin, but again only simple
stuff (no OLE, .dlls), and only in isolated places.
I will switch to non-UNICODE to see if this changes anything.
Viktor
On 2010 Apr 27, at 16:28, Teo Fonrouge wrote:
> Hello Viktor,
>
> On Apr 27, 2010, at 6:39 AM, Viktor Szakáts wrote:
>
>> Hi All,
[...]
>> 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
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
