Thread: [Tuxpaint-devel] Hidden bug on Windows?
An award-winning drawing program for children of all ages
Brought to you by:
wkendrick
Menu
▾
▴
tuxpaint-devel
|
From: TOYAMA Shin-i. <sh...@wm...> - 2021-10-11 22:59:51
|
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)
--
TOYAMA Shin-ichi mailto:sh...@wm...
|
|
From: Mark K. <tux...@cb...> - 2021-10-12 02:24:27
|
Hi Shin-ichi, On Mon, Oct 11, 2021 at 6:59 PM TOYAMA Shin-ichi <sh...@wm...> wrote: > I am concerned that there have been not a few reports of recent > versions not starting on Windows 10. > This issue appears to be the same issue I noticed a couple weeks ago on the macOS port of Tux Paint. The issue occurs intermittently, and only (in my case) in Korean mode. Adding extra code to debug the issue (e.g., by enabling DEBUG) changes the frequency of the issue, likely because the memory area that is the target of segfault is shifted by the extra code. Unfortunately I got side tracked by another issue and I hadn't had the time to look more at this issue. I did test some older macOS port of Tux Paint and confirmed the issue has existed for some time, though the timing seems too coincidental if you're seeing reports on the Windows port around the time I've noticed it on the macOS port. I'll take a look more when I get a chance -- please keep me posted if you get more information. Regards, Mark |
|
From: Bill K. <nb...@so...> - 2021-10-12 04:57:41
|
On Tue, Oct 12, 2021 at 07:59:38AM +0900, TOYAMA Shin-ichi wrote: > Hi developpers, > > I am concerned that there have been not a few reports of recent > versions not starting on Windows 10. Hi Shin-Ichi, I only saw that one bug reported at SourceForge. (https://sourceforge.net/p/tuxpaint/bugs/236/) 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? Now... I DID just try both 0.9.26-2 and 0.9.26-1 on one of my son's Windows 10 laptops, and it mimicked the behavior -- I double-click the Tux Paint launcher shortcut icon on the desktop, and nothing appears. :-/ When I re-installed 0.9.26, it works fine again. I wonder if I should point to 0.9.26 on the website ASAP, or wait and see if we can get a 0.9.26-3 that mends this issue...? The locale of my kids' laptops is English. Note, however, that the installer app for all 3 versions seem to launch in Spanish at first. (I forgot to mention that a few weeks ago, when I noticed it while installing 0.9.26 on my younger son's laptop.) -bill! > 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) > > > -- > TOYAMA Shin-ichi mailto:sh...@wm... > > > _______________________________________________ > Tuxpaint-devel mailing list > Tux...@li... > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel -- -bill! Sent from my computer |
|
From: Pere P. i C. <per...@gm...> - 2021-10-12 09:37:32
Attachments:
onscreenkeyboard.diff
|
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 :( 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) > > |
|
From: Pere P. i C. <per...@gm...> - 2021-10-12 19:06:26
|
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 |
|
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... |
|
From: Bill K. <nb...@so...> - 2021-10-13 00:02:35
|
On Wed, Oct 13, 2021 at 08:00:08AM +0900, TOYAMA Shin-ichi wrote: > 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. Okay, I can do this tonight. Thanks! -bill! > > 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... > > > _______________________________________________ > Tuxpaint-devel mailing list > Tux...@li... > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel -- -bill! Sent from my computer |
|
From: TOYAMA Shin-i. <sh...@wm...> - 2021-10-12 12:44:12
|
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 -- TOYAMA Shin-ichi mailto:sh...@wm... |
|
From: TOYAMA Shin-i. <sh...@wm...> - 2021-10-12 13:22:34
|
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 -- TOYAMA Shin-ichi mailto:sh...@wm... |
|
From: TOYAMA Shin-i. <sh...@wm...> - 2021-10-12 14:14:33
|
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 -- TOYAMA Shin-ichi mailto:sh...@wm... |
|
From: Bill K. <nb...@so...> - 2021-10-13 05:17:21
|
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
|
|
From: TOYAMA Shin-i. <sh...@wm...> - 2021-10-13 12:56:23
|
Bill Kendrick wrote in <202...@sh...> >There's been mention in this thread of 'tuxpaint.cfg' possibly >causing some problems. Can people share their problematic config files? I mentioned that 0.9.23 crashed when starting and it ran after deleting the config. This reminded me of a recent exchange with Vincent Putranto, who reported that he had installed 0.9.26 and it did not work, and then 0.9.25, which had worked before, did not start ever again. After trying various things to find out the recurrence condition, it seems that the old version does not start when the button size is changed from the standard value in 0.9.26. I think it is somehow unavoidable and there is nothing we should consider regarding this so far. -- TOYAMA Shin-ichi mailto:sh...@wm... |
|
From: Pere P. i C. <per...@gm...> - 2021-10-14 00:21:51
|
El dt. 12 de 10 de 2021 a les 22:17 -0700, en/na Bill Kendrick va escriure: > > 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.) > What happens here in a vboxed W10 is (0.9.26-2) displays the splash screen and crashes in it, the canvas and buttons never are seen. (0.9.26)tuxpaint --onscreen-keyboard starts fine and only crashes when you click in the Text or Label buttons, everything else is fine as far as I've tested, and sometimes it also shows the onscreen keyboard and lets you type in, but crashes when you change it. Once I set the Windows compatibility mode to W8 for Tux Paint, then both versions do not crash. I wonder what has changed in W10 as to make Tux Paint crashing, and what could we do to avoid the need to activate the compatibility thing. Thanks Pere |
|
From: Bill K. <nb...@so...> - 2021-10-13 06:56:12
Attachments:
win32_mtw_attempt.tar.gz
|
I've made a failed attempt. :) I can't get it to link for
some reason, and my brain is no longer working since it's
bedtime.
My objective here was to create "win32_mtw.c"/".h",
which includes functions to create the initial iconv descriptor
(so it isn't opened/closed all the time) during set-up and shutdown
of Tux Paint itself, and then mtw() lives there.
Please see attached, and see if it's useful, and if you can
get it to actually work. (Right now, the Makefile and source files
use it all the time, whereas in the end it should only do this
under #ifdef WIN32 environment. See the FIXMEs.)
Whew, anyway... definitely needs help in there!
-bill!
On Tue, Oct 12, 2021 at 10:17:14PM -0700, Bill Kendrick wrote:
> 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
--
-bill!
Sent from my computer
|
|
From: TOYAMA Shin-i. <sh...@wm...> - 2021-10-13 13:06:27
|
Thanks bill, It fails while linking with undefined sympol errors also in my build system so far. I will look into it tomorrow. Thanks again! Bill Kendrick wrote in <202...@sh...> >I've made a failed attempt. :) I can't get it to link for >some reason, and my brain is no longer working since it's >bedtime. > >My objective here was to create "win32_mtw.c"/".h", >which includes functions to create the initial iconv descriptor >(so it isn't opened/closed all the time) during set-up and shutdown >of Tux Paint itself, and then mtw() lives there. > >Please see attached, and see if it's useful, and if you can >get it to actually work. (Right now, the Makefile and source files >use it all the time, whereas in the end it should only do this >under #ifdef WIN32 environment. See the FIXMEs.) > >Whew, anyway... definitely needs help in there! > >-bill! -- TOYAMA Shin-ichi mailto:sh...@wm... |
|
From: Pere P. i C. <per...@gm...> - 2021-10-13 23:50:44
Attachments:
win32_mtw.c
win32_mtw.h
|
Thanks Bill,
Declaring extern the functions not linking seems to do the trick.
Also I had to set in and out to some value, otherwise it crashed,
and they have to be somewhat high in order the compose stuff works.
I am not sure if they are appropiate but in my tests that works.
Thanks
Pere
El dt. 12 de 10 de 2021 a les 23:56 -0700, en/na Bill Kendrick va escriure:
> I've made a failed attempt. :) I can't get it to link for
> some reason, and my brain is no longer working since it's
> bedtime.
>
> My objective here was to create "win32_mtw.c"/".h",
> which includes functions to create the initial iconv descriptor
> (so it isn't opened/closed all the time) during set-up and shutdown
> of Tux Paint itself, and then mtw() lives there.
>
> Please see attached, and see if it's useful, and if you can
> get it to actually work. (Right now, the Makefile and source files
> use it all the time, whereas in the end it should only do this
> under #ifdef WIN32 environment. See the FIXMEs.)
>
> Whew, anyway... definitely needs help in there!
>
> -bill!
>
> On Tue, Oct 12, 2021 at 10:17:14PM -0700, Bill Kendrick wrote:
> > 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
>
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X