Re: [Tuxpaint-devel] Hidden bug on Windows?

[Bill K. <nb...@so...>]

On Tue, Oct 12, 2021 at 11:37:22AM +0200, Pere Pujal i Carabantes wrote:
> Hi,
> 
> Could you try this?:
> git checkout 527fc27a2a185714545056246111119a74da4d95
> then apply onscreenkeyboard.diff
> and build.
> 
> The above works for me on W10, no crashes and keeps labels working,
> it discards the use of msys mbstowcs() and recovers the mtw() workaround.
> Unfortunately msys mbstowcs() seems not work outside ascii :(

I grabbed this, and removed a bunch of the #ifdef WIN32 tests,
so I could try things out with the mtw() code here on Linux.
One thing I notice right off is that the keyboard layout switch
is VERY sluggish.  With the regular Linux code, I could click
very quickly many times, and the keyboard would change basically
instantaneously.  Using the Win32-specific code we had, if I click
20 times very quickly, it's slow enough that it's still catching up,
and changing the keyboard layout back & forth, about 5 or 6 more times
after I stopped clicking.

I think the first thing I'm going to do is start with master branch,
move mtw() code into its own library, and try to make sure that it's
stable and working quickly for me under Linux, if possible.

I'd like to confirm with people -- the launch crashing on Windows
happens _immediately_, correct?  As in, a Tux Paint window never even
appears?  (That's what was happening for me with 0.9.26-1 and -2 on
my son's laptop.)

There's been mention in this thread of 'tuxpaint.cfg' possibly
causing some problems.  Can people share their problematic config files?

Thanks!

-bill!



> 
> And if it works for you, please somebody review the mtw() code, 
> I was a bit overhelmed when doing it and I really don't know why it 
> works for me now and why onscreen keyboard crashed before so some 
> more eyes on it would be nice.
> 
> BTW, Thanks Bill for the comments on the bug report :)
> 
> HTH
> Pere
> 
> 
> El dt. 12 de 10 de 2021 a les 07:59 +0900, en/na TOYAMA Shin-ichi va escriure:
> > Hi developpers,
> > 
> > I am concerned that there have been not a few reports of recent
> > versions not starting on Windows 10. 
> > 
> > One thing I can think of is that it doesn't start via gdb in the
> > MinGW/MSYS2 environment, although the fact that it doesn't 
> > reproduce in the normal environment at hand.
> > 
> > There may be some hidden bug. 
> > 
> > The following is a backtrace of a crash immediately after starting
> > with gdb. 
> > 
> > Anyone can see something from this?
> > 
> > -----------------------------------------------------------------------------
> > mingw64:$ gdb /usr/local/bin/tuxpaint
> > GNU gdb (GDB) 10.2
> > Copyright (C) 2021 Free Software Foundation, Inc.
> > 
> > < ... snip ... >
> > 
> > (gdb) run
> > Starting program: C:\msys64\usr\local\bin\tuxpaint.exe
> > [New Thread 19064.0x251c]
> > [New Thread 19064.0x5bdc]
> > [New Thread 19064.0x69b4]
> > [New Thread 19064.0x6760]
> > 
> > Thread 1 received signal SIGSEGV, Segmentation fault.
> > sm_add (sm=0xfeeefeeefeeefeee, seq=seq@entry=0x658c3feae1 "",
> >     unicode=unicode@entry=0x658c3feac0 L"??", flag=flag@entry=45 '-')
> >     at src/im.c:413
> > 413       STATE_MACHINE *sm_found = sm_search_shallow(sm, seq[0]);
> > 
> > (gdb) backtrace
> > #0  sm_add (sm=0xfeeefeeefeeefeee, seq=seq@entry=0x3e9b5fef61 "",
> >     unicode=unicode@entry=0x3e9b5fef40 L"??", flag=flag@entry=45 '-')
> >     at src/im.c:413
> > #1  0x00007ff6cb578237 in sm_add (sm=sm@entry=0x7ff6cb619a80 <cm+64>,
> >     seq=seq@entry=0x3e9b5fef60 "a", unicode=unicode@entry=0x3e9b5fef40 L"??",
> >     flag=<optimized out>) at src/im.c:465
> > #2  0x00007ff6cb57861a in charmap_add (flag=0x3e9b5ff060 "-",
> >     unicode=0x3e9b5fef40 L"??", seq=0x3e9b5fef60 "a", section=1,
> >     cm=0x7ff6cb619a40 <cm>) at src/im.c:523
> > #3  charmap_load (cm=cm@entry=0x7ff6cb619a40 <cm>,
> >     path=path@entry=0x7ff6cb5a2278 <language_to_locale_array+3960> "C:/msys64/usr/local/share/tuxpaint/im/ja.im") at src/im.c:619
> > #4  0x00007ff6cb5793c7 in im_event_ja (im=0x7ff6cb5ac500 <im_data>, ks=...)
> >     at src/im.c:1373
> > #5  0x00007ff6cb578782 in im_read (im=im@entry=0x7ff6cb5ac500 <im_data>,
> >     ks=...) at src/im.c:786
> > #6  0x00007ff6cb579e5f in im_event (im=0x7ff6cb5ac500 <im_data>)
> >     at src/im.c:812
> > #7  im_request (request=1, im=0x7ff6cb5ac500 <im_data>) at src/im.c:822
> > #8  im_init (im=im@entry=0x7ff6cb5ac500 <im_data>, lang=56) at src/im.c:1891
> > #9  0x00007ff6cb558418 in setup () at src/tuxpaint.c:24595
> > #10 0x00007ff6cb576e1c in SDL_main (argc=<optimized out>, argv=0x23a0396e200)
> >     at src/tuxpaint.c:25759
> > #11 0x00007ff6cb5850cb in console_main ()
> > #12 0x00007ff6cb5851a8 in WinMain ()
> > #13 0x00007ff6cb5413b1 in __tmainCRTStartup ()
> >     at C:/_/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:321
> > #14 0x00007ff6cb5414c6 in WinMainCRTStartup ()
> >     at C:/_/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:176
> > (gdb)
> > 
> > 

> diff --git a/src/onscreen_keyboard.c b/src/onscreen_keyboard.c
> index 4875a73b..67059ea7 100644
> --- a/src/onscreen_keyboard.c
> +++ b/src/onscreen_keyboard.c
> @@ -69,7 +69,7 @@ static void mtw(wchar_t * wtok, char *tok)
>    n = 255;
>    in = 250;
>    out = 250;
> -  ui16 = malloc(sizeof(Uint16) * 255);
> +  ui16 = malloc(255);
>    wrptr = (char *)ui16;
>  
>    trans = iconv_open("WCHAR_T", "UTF-8");
> diff --git a/src/tuxpaint.c b/src/tuxpaint.c
> index ebc47d7d..f1c05ae2 100644
> --- a/src/tuxpaint.c
> +++ b/src/tuxpaint.c
> @@ -348,12 +348,10 @@ static void mtw(wchar_t * wtok, char *tok)
>    char *wrptr = (char *)ui16;
>    size_t n, in, out;
>    iconv_t trans;
> -  wchar_t *wch;
>  
>    n = 255;
>    in = 250;
>    out = 250;
> -  wch = malloc(255);
>  
>    trans = iconv_open("WCHAR_T", "UTF-8");
>    iconv(trans, (const char **)&tok, &in, &wrptr, &out);


> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel


-- 
-bill!
Sent from my computer