Re: [Tuxpaint-devel] Hidden bug on Windows?
An award-winning drawing program for children of all ages
Brought to you by:
wkendrick
Menu
▾
▴
Re: [Tuxpaint-devel] Hidden bug on Windows?
|
From: TOYAMA Shin-i. <sh...@wm...> - 2021-10-12 23:00:41
|
Windows 7 on VMware also did not cause any crashes with 0.9.26. Then, I think we should cancel 0.9.26-1 and 0.9.26-2, revert to 0.9.26, and post it on the website as a known problem that occurs on Windows 10 and later so far. Pere Pujal i Carabantes wrote in <8a5...@gm...> >More on this, I've installed 0.9.22 and still crashes in W10. > >If I create a windows shortcut and in its properties I set >compatibility mode to W8 then it works fine. >Tested also 0.9.26 and it works fine here with the compatibility to W8 setted. > >HTH >Pere > > > > >El dt. 12 de 10 de 2021 a les 23:14 +0900, en/na TOYAMA Shin-ichi va escriure: >> Further invastigations... >> >> Rolled back to the commit 527fc27a2a185714545056246111119a74da4d95 >> Enabled -g option and disabled "strip" in Makefile >> Build tuxpaint and run it with gdb >> $ make bdist-win32 >> $ cd win32/bdist >> $ gdb tuxpaint >> (gdb) run >> -> it crashed as usual in im.c after loading im/ja.im >> Then I set LANG=C when invoking gdb >> $ LANG=C gdb tuxpaint >> (gdb) run >> -> it runs for the first time with gdb! (Yet another bug regarding locale?) >> OK, I tried --onscreen-keyboard option in gdb. >> (gdb) run --onscreen-keyboard >> -> it runs and does not crash at all! >> So, I ran it with LANG=C and without gdb >> $ LANG=C tuxpaint --onscreen-keyboard >> -> it crashed while changing osk layout. >> >> So confusing.... >> >> >> TOYAMA Shin-ichi wrote in <61658c10.4954%sh...@wm...> >> > To retroactively check from when this bug existed, I tried 0.9.23 >> > (zip version) considering that I changed the build system to MinGW >> > /MSYS2 after this build. >> > >> > Surprisingly, it did not start at all at first! >> > >> > Then I deleted the tuxpaint.cfg file in my per-user setting folder >> > and found it starts. >> > So it looks like there is another bug that causes it to crash if >> > different versions of the cfg exists, which seems to be the case >> > with Vincent Putranto, I guess. >> > >> > Anyway, I also confirmed that the onscreen keyboard crash bug >> > already exists at this point and has nothing to do with the change >> > of build system. >> > >> > Still need to investigate... >> > >> > >> > TOYAMA Shin-ichi wrote in <61658312.4953%sh...@wm...> >> > > Bill Kendrick wrote in <202...@sh...> >> > > > I didn't see anyone mention it over on Twitter (even after asking >> > > > for people to tell me if they're using 0.9.26-2). >> > > > >> > > > Where else are you seeing reports? >> > > >> > > Yes, reports from Vincent Putranto is is in my mind. >> > > >> > > Pere Pujal i Carabantes wrote in >> > > <693...@gm...> >> > > > 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 :( >> > > > >> > > > 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. >> > > >> > > Thanks! >> > > >> > > It may have been premature that I simply removed the windows >> > > specific mtw() without thinking about mbstowcs() not handling >> > > multibyte correctly. >> > > >> > > So, I rewound the git to before the point and tried a build with >> > > the pere's patch applied, and unfortunately, the crash bug when >> > > switching the onscreen keybord layout reproduced. >> > > >> > > Well, it looks like I need to spend some more time to figure out >> > > how to fix this. >> > > >> > > >> > > > 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) >> > > > > >> > > > > >> > > > ---- inline file >> > > > ---- inline file >> > > > _______________________________________________ >> > > > Tuxpaint-devel mailing list >> > > > Tux...@li... >> > > > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel > > > >_______________________________________________ >Tuxpaint-devel mailing list >Tux...@li... >https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel -- TOYAMA Shin-ichi mailto:sh...@wm... |
