Thread: Re: [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-14 03:06:40
|
Hi,
Thanks.
It compiled but crashed on windows.
Did you tested on linux?
By the way, I tested it in a primitive fprintf(stderr,...) style,
it crashed after gettokens() was called 41523 times from
load_composemap().
Could there be a clue here?
Still investigating...
Pere Pujal i Carabantes wrote in <ffe...@gm...>
>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
>---- 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-14 11:20:17
|
Hi, It is becoming clear. I suppose it was wrong to delete WIN32 specific code in load_info_about_label_surface() function for 0.9.26-2. Pere Pujal i Carabantes wrote in <693...@gm...> >Unfortunately msys mbstowcs() seems not work outside ascii :( Because I am not so sure about this, I removed mtw() from onscreen_keyboard.c and tuxpaint.c again and just replaced mtw() in the label function with mbstowcs() not deleting all the windows specific part. It seems to work fine for me. No crash, rapid osk layout change and no problem when using labels and osk with Japanese characters! Could you please give a try to 0.9.26-3 packages in https://z1.plala.jp/tuxpaint/release/0.9.26-3/ If they are fine also for you, I will commit the changes to the git repo. Thanks! -- TOYAMA Shin-ichi mailto:sh...@wm... |
|
From: TOYAMA Shin-i. <sh...@wm...> - 2021-10-14 12:16:50
|
I was wrong again ;-< It crash when re-opening drawing with labels..... Sorry for the mess. TOYAMA Shin-ichi wrote in <61681264.4961%sh...@wm...> >Hi, > >It is becoming clear. > >I suppose it was wrong to delete WIN32 specific code in >load_info_about_label_surface() function for 0.9.26-2. > >Pere Pujal i Carabantes wrote in ><693...@gm...> >>Unfortunately msys mbstowcs() seems not work outside ascii :( > >Because I am not so sure about this, I removed mtw() from >onscreen_keyboard.c and tuxpaint.c again and just replaced mtw() >in the label function with mbstowcs() not deleting all the >windows specific part. > >It seems to work fine for me. >No crash, rapid osk layout change and no problem when using labels >and osk with Japanese characters! > >Could you please give a try to 0.9.26-3 packages in > > https://z1.plala.jp/tuxpaint/release/0.9.26-3/ > >If they are fine also for you, I will commit the changes to the >git repo. > >Thanks! -- TOYAMA Shin-ichi mailto:sh...@wm... |
|
From: TOYAMA Shin-i. <sh...@wm...> - 2021-10-16 00:04:40
|
Thanks Pere! Then I should get all the mtw() staff back and dig into the deep. I will focus on Onscreen Keyboard at first. I am wondering if it might be worth trying to directly use mbstowcs_s() on Windows to avoid using iconv(). https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/mbstowcs-s-mbstowcs-s-l?view=msvc-160 Hrm... Pere Pujal i Carabantes wrote in <b7c...@gm...> >Hi, > >El dv. 15 de 10 de 2021 a les 13:43 +0900, en/na TOYAMA Shin-ichi va escriure: >> Hi, >> >> I strongly hope this will be a final report. >> >> Here is a brief (long?) history; >> >> 1) OSK crash regarding libiconv reported in, >> https://sourceforge.net/p/tuxpaint/bugs/235/ >> 2) Win32 specific codes mtw() using iconv(), alternative to >> mbstowcs(), were removed and once seemed to work fine. >> 3) Found that it still crash only on Windows10 and later. >> 4) Trial to sepalate mtw() to single lib failed. >> 5) Found that it crash not when using OSK, but when loading >> labels embedded in png drowings. >> >> At this point, I remember that Bill mentiond that iconv() is >> also used in do_png_embed_data() in bugs/235 above. >> >> Then, I also removed "#ifdef WIN32" part in this function, and >> it seems to work quite fine! >> >> Patch to 0.9.26 is attached and binary packages are available >> from, >> >> https://z1.plala.jp/tuxpaint/release/0.9.26-4/ > >I am sorry to say it still doesn't work fine with labels, >it seems to work fine if the drawing stays in Windows, but when you >import/export a drawing between Linux and Windows then there are >problems. > >I've made a drawing in Linux (800x600) with all the strings duplicated, >once as text and again as labels, you could get it at >https://provant.freeddns.org/pere/public_html/developing/20211015/20211015205933.png > >See how only the first label string, made with the plain abcd row >of the onscreen keyboard is displayed in 0.9.26-4, instead 0.9.26 >displays and edits all labels correctly(both with compatibility >mode activated in W10). > > > >> >> By the way, I am quite at a loss what for those WIN32 specific >> code were needed, because patched code also compiled on the old >> mingw/msys environment and works fine on Windows XP just by >> defining lacking strtok_r() in onscreen_keyboard.c as follows. >> >> #define strtok_r(line, delim, pointer) strtok(line, delim) >> >> I am not sure but those code might have been tweaked when >> compiling in older build environment. > >I really don't know, I remember struggling and testing tons of things >until found something that seemed to make labels compatible >between Linux and Windows, not sure if we are talking about the same code. > > >Thanks >Pere > > >> >> Anyway, I think very carefull review and tests are required >> before releasing them. >> >> Hope your help! >> >> Thanks. >> >> >> TOYAMA Shin-ichi wrote in <6168e3c0.4965%sh...@wm...> >> > Just a brief report. >> > >> > Deleting mtw() seems to be OK. >> > >> > I found crash when loading drowing with labels occur in other >> > part. >> > >> > ------------------------------------------------------------ >> > Thread 1 received signal SIGSEGV, Segmentation fault. >> > 0x00007ffd86ab7f09 in msvcrt!memmove () from C:\WINDOWS\System32\msvcrt.dll >> > (gdb) backtrace >> > #0 0x00007ffd86ab7f09 in msvcrt!memmove () >> > from C:\WINDOWS\System32\msvcrt.dll >> > #1 0x00007ff6e502743e in load_embedded_data () >> > #2 0x00007ff6e50281f2 in load_current () >> > #3 0x00007ff6e5036842 in SDL_main () >> > #4 0x00007ff6e504461b in console_main () >> > #5 0x00007ff6e50446f8 in WinMain () >> > #6 0x00007ff6e50013b1 in __tmainCRTStartup () >> > at C:/_/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:321 >> > #7 0x00007ff6e50014c6 in WinMainCRTStartup () >> > at C:/_/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:176 >> > ------------------------------------------------------------ >> > >> > Thanks. >> > >> > TOYAMA Shin-ichi wrote in <61681fa6.4962%sh...@wm...> >> > > I was wrong again ;-< >> > > >> > > It crash when re-opening drawing with labels..... >> > > >> > > Sorry for the mess. >> > > >> > > >> > > TOYAMA Shin-ichi wrote in <61681264.4961%sh...@wm...> >> > > > Hi, >> > > > >> > > > It is becoming clear. >> > > > >> > > > I suppose it was wrong to delete WIN32 specific code in >> > > > load_info_about_label_surface() function for 0.9.26-2. >> > > > >> > > > Pere Pujal i Carabantes wrote in >> > > > <693...@gm...> >> > > > > Unfortunately msys mbstowcs() seems not work outside ascii :( >> > > > >> > > > Because I am not so sure about this, I removed mtw() from >> > > > onscreen_keyboard.c and tuxpaint.c again and just replaced mtw() >> > > > in the label function with mbstowcs() not deleting all the >> > > > windows specific part. >> > > > >> > > > It seems to work fine for me. >> > > > No crash, rapid osk layout change and no problem when using labels >> > > > and osk with Japanese characters! >> > > > >> > > > Could you please give a try to 0.9.26-3 packages in >> > > > >> > > > https://z1.plala.jp/tuxpaint/release/0.9.26-3/ >> > > > >> > > > If they are fine also for you, I will commit the changes to the >> > > > git repo. >> > > > >> > > > Thanks! >> >> _______________________________________________ >> 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: TOYAMA Shin-i. <sh...@wm...> - 2021-10-16 13:46:54
|
Great! Thanks! Vincent Putranto wrote in <CAJ...@ma...> >Hi Shin-ichi, >this one seems work on me. > >Many Thanks. >Vincent > >On Sat, Oct 16, 2021 at 8:11 PM TOYAMA Shin-ichi <sh...@wm...> >wrote: > >> # Cc'ing to Vincent who kindly gave us crash reports. >> >> Hi, Pere >> >> Thank you for testing the FixOSK version. >> It still has crash bug here as follows; >> >> * Launch it, draw label, save and quit. >> * Launch it again. >> * Crash ;-< >> >> I have carefully reviewed mtw() in tuxpaint.c and made some >> changes (patch attached), which works fine here. >> >> Packages compiled as 0.9.26-5 are available in >> >> https://z1.plala.jp/tuxpaint/release/0.9.26-5/ (5!!) >> >> Could you give them final tests ? >> I pray that this will work out this time. >> >> Hi Vincent! >> >> Although you reported me that you could run official release >> 0.9.26 by removing user's directory and re-installing it, it surly >> has problems regarding onscreen keyboard and labels. >> >> Now I believe we are almost close to the final solution. >> Please wait a little more until next bugfix version released. >> >> Sorry for your inconvenience. >> >> Hi Bill, >> >> Please release 0.9.26-5 if Pere would give us a positive >> report and you don't see any problem in onscreen_keyboard.c and >> mtw() in tuxpaint.c. >> Then, I will commit the changes to the latest git repo. >> >> Thanks in advance! >> >> -- >> shin1 >> >> Pere Pujal i Carabantes wrote in < >> e5a...@gm...> >> >Hi Shin-ichi >> > >> >El ds. 16 de 10 de 2021 a les 16:57 +0900, en/na TOYAMA Shin-ichi va >> escriure: >> >> Hi, >> >> >> >> mbstowcs_s() seemed to improve the behavior of AltGr modifire, but >> >> the composer did not work correctly. >> >> >> >> So, I tried to use another Windows library function >> >> MultiByteToWideChar(), >> >> >> >> >> > >> >https://docs.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-multibytetowidechar >> >> >> >> Then, I think the onscreen keyboard now works quickly, correctly, >> >> and does not crash! (A patch attached) >> > >> >I've tried to apply to current git master and it failed to apply, >> >then I checked out 527fc27a and it applied fine. >> >Compiled it whith make bdist-win32 and it runs fine, no crashes >> >at all, even opening a file with labels :) >> > >> >> >> >> Although it still crashes when opening a drawing that contains >> >> label(s), could you please confirm if the onscreen keyboard works >> >> perfectly in the mean time? >> >> >> >> https://z1.plala.jp/tuxpaint/testing/windows10/ >> > >> >Installed the tuxpaint-0.9.26-windows-x86_64-FixOSK-installer.exe >> >The onscreen keyboard looks fine :) >> >And more, it seems to not need the compatibility to W8 setted, >> >I have to reboot W10 to make sure but looks great :) >> > >> >Thanks >> >Pere >> > >> >> >> >> Step by step .... >> >> >> >> -- >> >> Shin-ichi >> >> >> >> TOYAMA Shin-ichi wrote in <616a170e.4969%sh...@wm...> >> >> > Thanks Pere! >> >> > >> >> > Then I should get all the mtw() staff back and dig into the >> >> > deep. >> >> > >> >> > I will focus on Onscreen Keyboard at first. >> >> > I am wondering if it might be worth trying to directly use >> >> > mbstowcs_s() on Windows to avoid using iconv(). >> >> > >> >> > >> > >> >https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/mbstowcs-s-mbstowcs-s-l?view=msvc-160 >> >> > >> >> > Hrm... >> >> > >> >> > Pere Pujal i Carabantes wrote in >> >> > <b7c...@gm...> >> >> > > Hi, >> >> > > >> >> > > El dv. 15 de 10 de 2021 a les 13:43 +0900, en/na TOYAMA Shin-ichi >> va >> >escriure: >> >> > > > Hi, >> >> > > > >> >> > > > I strongly hope this will be a final report. >> >> > > > >> >> > > > Here is a brief (long?) history; >> >> > > > >> >> > > > 1) OSK crash regarding libiconv reported in, >> >> > > > https://sourceforge.net/p/tuxpaint/bugs/235/ >> >> > > > 2) Win32 specific codes mtw() using iconv(), alternative to >> >> > > > mbstowcs(), were removed and once seemed to work fine. >> >> > > > 3) Found that it still crash only on Windows10 and later. >> >> > > > 4) Trial to sepalate mtw() to single lib failed. >> >> > > > 5) Found that it crash not when using OSK, but when loading >> >> > > > labels embedded in png drowings. >> >> > > > >> >> > > > At this point, I remember that Bill mentiond that iconv() is >> >> > > > also used in do_png_embed_data() in bugs/235 above. >> >> > > > >> >> > > > Then, I also removed "#ifdef WIN32" part in this function, and >> >> > > > it seems to work quite fine! >> >> > > > >> >> > > > Patch to 0.9.26 is attached and binary packages are available >> >> > > > from, >> >> > > > >> >> > > > https://z1.plala.jp/tuxpaint/release/0.9.26-4/ >> >> > > >> >> > > I am sorry to say it still doesn't work fine with labels, >> >> > > it seems to work fine if the drawing stays in Windows, but when you >> >> > > import/export a drawing between Linux and Windows then there are >> >> > > problems. >> >> > > >> >> > > I've made a drawing in Linux (800x600) with all the strings >> duplicated, >> >> > > once as text and again as labels, you could get it at >> >> > > >> > >> >https://provant.freeddns.org/pere/public_html/developing/20211015/20211015205933.png >> >> > > >> >> > > See how only the first label string, made with the plain abcd row >> >> > > of the onscreen keyboard is displayed in 0.9.26-4, instead 0.9.26 >> >> > > displays and edits all labels correctly(both with compatibility >> >> > > mode activated in W10). >> >> > > >> >> > > >> >> > > >> >> > > > By the way, I am quite at a loss what for those WIN32 specific >> >> > > > code were needed, because patched code also compiled on the old >> >> > > > mingw/msys environment and works fine on Windows XP just by >> >> > > > defining lacking strtok_r() in onscreen_keyboard.c as follows. >> >> > > > >> >> > > > #define strtok_r(line, delim, pointer) strtok(line, delim) >> >> > > > >> >> > > > I am not sure but those code might have been tweaked when >> >> > > > compiling in older build environment. >> >> > > >> >> > > I really don't know, I remember struggling and testing tons of >> things >> >> > > until found something that seemed to make labels compatible >> >> > > between Linux and Windows, not sure if we are talking about the >> same code. >> >> > > >> >> > > >> >> > > Thanks >> >> > > Pere >> >> > > >> >> > > >> >> > > > Anyway, I think very carefull review and tests are required >> >> > > > before releasing them. >> >> > > > >> >> > > > Hope your help! >> >> > > > >> >> > > > Thanks. >> >> > > > >> >> > > > >> >> > > > TOYAMA Shin-ichi wrote in <6168e3c0.4965%sh...@wm...> >> >> > > > > Just a brief report. >> >> > > > > >> >> > > > > Deleting mtw() seems to be OK. >> >> > > > > >> >> > > > > I found crash when loading drowing with labels occur in other >> >> > > > > part. >> >> > > > > >> >> > > > > ------------------------------------------------------------ >> >> > > > > Thread 1 received signal SIGSEGV, Segmentation fault. >> >> > > > > 0x00007ffd86ab7f09 in msvcrt!memmove () from >> >C:\WINDOWS\System32\msvcrt.dll >> >> > > > > (gdb) backtrace >> >> > > > > #0 0x00007ffd86ab7f09 in msvcrt!memmove () >> >> > > > > from C:\WINDOWS\System32\msvcrt.dll >> >> > > > > #1 0x00007ff6e502743e in load_embedded_data () >> >> > > > > #2 0x00007ff6e50281f2 in load_current () >> >> > > > > #3 0x00007ff6e5036842 in SDL_main () >> >> > > > > #4 0x00007ff6e504461b in console_main () >> >> > > > > #5 0x00007ff6e50446f8 in WinMain () >> >> > > > > #6 0x00007ff6e50013b1 in __tmainCRTStartup () >> >> > > > > at >> >C:/_/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:321 >> >> > > > > #7 0x00007ff6e50014c6 in WinMainCRTStartup () >> >> > > > > at >> >C:/_/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:176 >> >> > > > > ------------------------------------------------------------ >> >> > > > > >> >> > > > > Thanks. >> >> > > > > >> >> > > > > TOYAMA Shin-ichi wrote in < >> 61681fa6.4962%sh...@wm...> >> >> > > > > > I was wrong again ;-< >> >> > > > > > >> >> > > > > > It crash when re-opening drawing with labels..... >> >> > > > > > >> >> > > > > > Sorry for the mess. >> >> > > > > > >> >> > > > > > >> >> > > > > > TOYAMA Shin-ichi wrote in < >> 61681264.4961%sh...@wm...> >> >> > > > > > > Hi, >> >> > > > > > > >> >> > > > > > > It is becoming clear. >> >> > > > > > > >> >> > > > > > > I suppose it was wrong to delete WIN32 specific code in >> >> > > > > > > load_info_about_label_surface() function for 0.9.26-2. >> >> > > > > > > >> >> > > > > > > Pere Pujal i Carabantes wrote in >> >> > > > > > > <693...@gm...> >> >> > > > > > > > Unfortunately msys mbstowcs() seems not work outside >> ascii :( >> >> > > > > > > >> >> > > > > > > Because I am not so sure about this, I removed mtw() from >> >> > > > > > > onscreen_keyboard.c and tuxpaint.c again and just replaced >> mtw() >> >> > > > > > > in the label function with mbstowcs() not deleting all the >> >> > > > > > > windows specific part. >> >> > > > > > > >> >> > > > > > > It seems to work fine for me. >> >> > > > > > > No crash, rapid osk layout change and no problem when using >> >labels >> >> > > > > > > and osk with Japanese characters! >> >> > > > > > > >> >> > > > > > > Could you please give a try to 0.9.26-3 packages in >> >> > > > > > > >> >> > > > > > > https://z1.plala.jp/tuxpaint/release/0.9.26-3/ >> >> > > > > > > >> >> > > > > > > If they are fine also for you, I will commit the changes to >> the >> >> > > > > > > git repo. >> >> > > > > > > >> >> > > > > > > Thanks! >> >> > > > >> >_______________________________________________ >> >Tuxpaint-devel mailing list >> >Tux...@li... >> >https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel >> >> -- >> TOYAMA Shin-ichi mailto:sh...@wm... > > > >-- > > >Regards, > > >*Vincentius A.P.* > > >The information contained in this communication is intended solely for the >use of the individual or entity to whom it is addressed and others >authorized to receive it. It may contain confidential or legally privileged >information. If you are not the intended recipient you are notified that >any disclosure, copying, distribution or taking any action in reliance on >the contents of this information is strictly prohibited and may be illegal. > >*PT. Indosari Makmur Persada* is not liable if an e-mail or attachment is >altered without its written consent. The limitations of liability contained >in this disclaimer may not apply in your jurisdiction, where not allowed by >the law. -- TOYAMA Shin-ichi mailto:sh...@wm... |
|
From: TOYAMA Shin-i. <sh...@wm...> - 2021-10-16 07:58:09
Attachments:
tuxpaint-0.9.26-FixOSK.patch
|
Hi, mbstowcs_s() seemed to improve the behavior of AltGr modifire, but the composer did not work correctly. So, I tried to use another Windows library function MultiByteToWideChar(), https://docs.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-multibytetowidechar Then, I think the onscreen keyboard now works quickly, correctly, and does not crash! (A patch attached) Although it still crashes when opening a drawing that contains label(s), could you please confirm if the onscreen keyboard works perfectly in the mean time? https://z1.plala.jp/tuxpaint/testing/windows10/ Step by step .... -- Shin-ichi TOYAMA Shin-ichi wrote in <616a170e.4969%sh...@wm...> >Thanks Pere! > >Then I should get all the mtw() staff back and dig into the >deep. > >I will focus on Onscreen Keyboard at first. >I am wondering if it might be worth trying to directly use >mbstowcs_s() on Windows to avoid using iconv(). > >https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/mbstowcs-s-mbstowcs-s-l?view=msvc-160 > >Hrm... > >Pere Pujal i Carabantes wrote in ><b7c...@gm...> >>Hi, >> >>El dv. 15 de 10 de 2021 a les 13:43 +0900, en/na TOYAMA Shin-ichi va escriure: >>> Hi, >>> >>> I strongly hope this will be a final report. >>> >>> Here is a brief (long?) history; >>> >>> 1) OSK crash regarding libiconv reported in, >>> https://sourceforge.net/p/tuxpaint/bugs/235/ >>> 2) Win32 specific codes mtw() using iconv(), alternative to >>> mbstowcs(), were removed and once seemed to work fine. >>> 3) Found that it still crash only on Windows10 and later. >>> 4) Trial to sepalate mtw() to single lib failed. >>> 5) Found that it crash not when using OSK, but when loading >>> labels embedded in png drowings. >>> >>> At this point, I remember that Bill mentiond that iconv() is >>> also used in do_png_embed_data() in bugs/235 above. >>> >>> Then, I also removed "#ifdef WIN32" part in this function, and >>> it seems to work quite fine! >>> >>> Patch to 0.9.26 is attached and binary packages are available >>> from, >>> >>> https://z1.plala.jp/tuxpaint/release/0.9.26-4/ >> >>I am sorry to say it still doesn't work fine with labels, >>it seems to work fine if the drawing stays in Windows, but when you >>import/export a drawing between Linux and Windows then there are >>problems. >> >>I've made a drawing in Linux (800x600) with all the strings duplicated, >>once as text and again as labels, you could get it at >>https://provant.freeddns.org/pere/public_html/developing/20211015/20211015205933.png >> >>See how only the first label string, made with the plain abcd row >>of the onscreen keyboard is displayed in 0.9.26-4, instead 0.9.26 >>displays and edits all labels correctly(both with compatibility >>mode activated in W10). >> >> >> >>> >>> By the way, I am quite at a loss what for those WIN32 specific >>> code were needed, because patched code also compiled on the old >>> mingw/msys environment and works fine on Windows XP just by >>> defining lacking strtok_r() in onscreen_keyboard.c as follows. >>> >>> #define strtok_r(line, delim, pointer) strtok(line, delim) >>> >>> I am not sure but those code might have been tweaked when >>> compiling in older build environment. >> >>I really don't know, I remember struggling and testing tons of things >>until found something that seemed to make labels compatible >>between Linux and Windows, not sure if we are talking about the same code. >> >> >>Thanks >>Pere >> >> >>> >>> Anyway, I think very carefull review and tests are required >>> before releasing them. >>> >>> Hope your help! >>> >>> Thanks. >>> >>> >>> TOYAMA Shin-ichi wrote in <6168e3c0.4965%sh...@wm...> >>> > Just a brief report. >>> > >>> > Deleting mtw() seems to be OK. >>> > >>> > I found crash when loading drowing with labels occur in other >>> > part. >>> > >>> > ------------------------------------------------------------ >>> > Thread 1 received signal SIGSEGV, Segmentation fault. >>> > 0x00007ffd86ab7f09 in msvcrt!memmove () from C:\WINDOWS\System32\msvcrt.dll >>> > (gdb) backtrace >>> > #0 0x00007ffd86ab7f09 in msvcrt!memmove () >>> > from C:\WINDOWS\System32\msvcrt.dll >>> > #1 0x00007ff6e502743e in load_embedded_data () >>> > #2 0x00007ff6e50281f2 in load_current () >>> > #3 0x00007ff6e5036842 in SDL_main () >>> > #4 0x00007ff6e504461b in console_main () >>> > #5 0x00007ff6e50446f8 in WinMain () >>> > #6 0x00007ff6e50013b1 in __tmainCRTStartup () >>> > at C:/_/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:321 >>> > #7 0x00007ff6e50014c6 in WinMainCRTStartup () >>> > at C:/_/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:176 >>> > ------------------------------------------------------------ >>> > >>> > Thanks. >>> > >>> > TOYAMA Shin-ichi wrote in <61681fa6.4962%sh...@wm...> >>> > > I was wrong again ;-< >>> > > >>> > > It crash when re-opening drawing with labels..... >>> > > >>> > > Sorry for the mess. >>> > > >>> > > >>> > > TOYAMA Shin-ichi wrote in <61681264.4961%sh...@wm...> >>> > > > Hi, >>> > > > >>> > > > It is becoming clear. >>> > > > >>> > > > I suppose it was wrong to delete WIN32 specific code in >>> > > > load_info_about_label_surface() function for 0.9.26-2. >>> > > > >>> > > > Pere Pujal i Carabantes wrote in >>> > > > <693...@gm...> >>> > > > > Unfortunately msys mbstowcs() seems not work outside ascii :( >>> > > > >>> > > > Because I am not so sure about this, I removed mtw() from >>> > > > onscreen_keyboard.c and tuxpaint.c again and just replaced mtw() >>> > > > in the label function with mbstowcs() not deleting all the >>> > > > windows specific part. >>> > > > >>> > > > It seems to work fine for me. >>> > > > No crash, rapid osk layout change and no problem when using labels >>> > > > and osk with Japanese characters! >>> > > > >>> > > > Could you please give a try to 0.9.26-3 packages in >>> > > > >>> > > > https://z1.plala.jp/tuxpaint/release/0.9.26-3/ >>> > > > >>> > > > If they are fine also for you, I will commit the changes to the >>> > > > git repo. >>> > > > >>> > > > Thanks! >>> >>> _______________________________________________ >>> 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: TOYAMA Shin-i. <sh...@wm...> - 2021-10-17 00:40:28
|
Hi Bill, Pere Pujal i Carabantes wrote in <041...@gm...> >> Packages compiled as 0.9.26-5 are available in >> >> https://z1.plala.jp/tuxpaint/release/0.9.26-5/ (5!!) >> >> Could you give them final tests ? >> I pray that this will work out this time. > >As far as I've tested it works fine in W10: >No need to enable compatibility to W8 to make it running. >No crashes with labels. >No crashes with onscreen keyboard. >Drawings can be exported/imported from/to Linux/Windows without >labels being corrupted. So, I believe those two crash bug on windows10 have been fixed finally. By the way, patched 0.9.26 also compiled on the old build system for 2000 and XP, but it did not run. Then, I think that the initial tweak for windows on the OSK was not a mistake. I guess that this bug has been existing since when I changed the build system to MinGW/MSYS2 and become apparent in Windows10. I think every windows user, except XP/2000, would be suggested to upgrade to 0.9.26-5. Thanks. -- TOYAMA Shin-ichi mailto:sh...@wm... |
|
From: TOYAMA Shin-i. <sh...@wm...> - 2021-10-15 02:13:35
|
Just a brief report.
Deleting mtw() seems to be OK.
I found crash when loading drowing with labels occur in other
part.
------------------------------------------------------------
Thread 1 received signal SIGSEGV, Segmentation fault.
0x00007ffd86ab7f09 in msvcrt!memmove () from C:\WINDOWS\System32\msvcrt.dll
(gdb) backtrace
#0 0x00007ffd86ab7f09 in msvcrt!memmove ()
from C:\WINDOWS\System32\msvcrt.dll
#1 0x00007ff6e502743e in load_embedded_data ()
#2 0x00007ff6e50281f2 in load_current ()
#3 0x00007ff6e5036842 in SDL_main ()
#4 0x00007ff6e504461b in console_main ()
#5 0x00007ff6e50446f8 in WinMain ()
#6 0x00007ff6e50013b1 in __tmainCRTStartup ()
at C:/_/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:321
#7 0x00007ff6e50014c6 in WinMainCRTStartup ()
at C:/_/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:176
------------------------------------------------------------
Thanks.
TOYAMA Shin-ichi wrote in <61681fa6.4962%sh...@wm...>
>I was wrong again ;-<
>
>It crash when re-opening drawing with labels.....
>
>Sorry for the mess.
>
>
>TOYAMA Shin-ichi wrote in <61681264.4961%sh...@wm...>
>>Hi,
>>
>>It is becoming clear.
>>
>>I suppose it was wrong to delete WIN32 specific code in
>>load_info_about_label_surface() function for 0.9.26-2.
>>
>>Pere Pujal i Carabantes wrote in
>><693...@gm...>
>>>Unfortunately msys mbstowcs() seems not work outside ascii :(
>>
>>Because I am not so sure about this, I removed mtw() from
>>onscreen_keyboard.c and tuxpaint.c again and just replaced mtw()
>>in the label function with mbstowcs() not deleting all the
>>windows specific part.
>>
>>It seems to work fine for me.
>>No crash, rapid osk layout change and no problem when using labels
>>and osk with Japanese characters!
>>
>>Could you please give a try to 0.9.26-3 packages in
>>
>> https://z1.plala.jp/tuxpaint/release/0.9.26-3/
>>
>>If they are fine also for you, I will commit the changes to the
>>git repo.
>>
>>Thanks!
--
TOYAMA Shin-ichi mailto:sh...@wm...
|
|
From: TOYAMA Shin-i. <sh...@wm...> - 2021-10-15 04:43:34
Attachments:
tuxpaint-0.9.26-noiconv.patch
|
Hi, I strongly hope this will be a final report. Here is a brief (long?) history; 1) OSK crash regarding libiconv reported in, https://sourceforge.net/p/tuxpaint/bugs/235/ 2) Win32 specific codes mtw() using iconv(), alternative to mbstowcs(), were removed and once seemed to work fine. 3) Found that it still crash only on Windows10 and later. 4) Trial to sepalate mtw() to single lib failed. 5) Found that it crash not when using OSK, but when loading labels embedded in png drowings. At this point, I remember that Bill mentiond that iconv() is also used in do_png_embed_data() in bugs/235 above. Then, I also removed "#ifdef WIN32" part in this function, and it seems to work quite fine! Patch to 0.9.26 is attached and binary packages are available from, https://z1.plala.jp/tuxpaint/release/0.9.26-4/ By the way, I am quite at a loss what for those WIN32 specific code were needed, because patched code also compiled on the old mingw/msys environment and works fine on Windows XP just by defining lacking strtok_r() in onscreen_keyboard.c as follows. #define strtok_r(line, delim, pointer) strtok(line, delim) I am not sure but those code might have been tweaked when compiling in older build environment. Anyway, I think very carefull review and tests are required before releasing them. Hope your help! Thanks. TOYAMA Shin-ichi wrote in <6168e3c0.4965%sh...@wm...> >Just a brief report. > >Deleting mtw() seems to be OK. > >I found crash when loading drowing with labels occur in other >part. > >------------------------------------------------------------ >Thread 1 received signal SIGSEGV, Segmentation fault. >0x00007ffd86ab7f09 in msvcrt!memmove () from C:\WINDOWS\System32\msvcrt.dll >(gdb) backtrace >#0 0x00007ffd86ab7f09 in msvcrt!memmove () > from C:\WINDOWS\System32\msvcrt.dll >#1 0x00007ff6e502743e in load_embedded_data () >#2 0x00007ff6e50281f2 in load_current () >#3 0x00007ff6e5036842 in SDL_main () >#4 0x00007ff6e504461b in console_main () >#5 0x00007ff6e50446f8 in WinMain () >#6 0x00007ff6e50013b1 in __tmainCRTStartup () > at C:/_/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:321 >#7 0x00007ff6e50014c6 in WinMainCRTStartup () > at C:/_/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:176 >------------------------------------------------------------ > >Thanks. > >TOYAMA Shin-ichi wrote in <61681fa6.4962%sh...@wm...> >>I was wrong again ;-< >> >>It crash when re-opening drawing with labels..... >> >>Sorry for the mess. >> >> >>TOYAMA Shin-ichi wrote in <61681264.4961%sh...@wm...> >>>Hi, >>> >>>It is becoming clear. >>> >>>I suppose it was wrong to delete WIN32 specific code in >>>load_info_about_label_surface() function for 0.9.26-2. >>> >>>Pere Pujal i Carabantes wrote in >>><693...@gm...> >>>>Unfortunately msys mbstowcs() seems not work outside ascii :( >>> >>>Because I am not so sure about this, I removed mtw() from >>>onscreen_keyboard.c and tuxpaint.c again and just replaced mtw() >>>in the label function with mbstowcs() not deleting all the >>>windows specific part. >>> >>>It seems to work fine for me. >>>No crash, rapid osk layout change and no problem when using labels >>>and osk with Japanese characters! >>> >>>Could you please give a try to 0.9.26-3 packages in >>> >>> https://z1.plala.jp/tuxpaint/release/0.9.26-3/ >>> >>>If they are fine also for you, I will commit the changes to the >>>git repo. >>> >>>Thanks! -- TOYAMA Shin-ichi mailto:sh...@wm... |
|
From: Pere P. i C. <per...@gm...> - 2021-10-16 11:13:38
|
Hi Shin-ichi El ds. 16 de 10 de 2021 a les 16:57 +0900, en/na TOYAMA Shin-ichi va escriure: > Hi, > > mbstowcs_s() seemed to improve the behavior of AltGr modifire, but > the composer did not work correctly. > > So, I tried to use another Windows library function > MultiByteToWideChar(), > > https://docs.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-multibytetowidechar > > Then, I think the onscreen keyboard now works quickly, correctly, > and does not crash! (A patch attached) I've tried to apply to current git master and it failed to apply, then I checked out 527fc27a and it applied fine. Compiled it whith make bdist-win32 and it runs fine, no crashes at all, even opening a file with labels :) > > Although it still crashes when opening a drawing that contains > label(s), could you please confirm if the onscreen keyboard works > perfectly in the mean time? > > https://z1.plala.jp/tuxpaint/testing/windows10/ Installed the tuxpaint-0.9.26-windows-x86_64-FixOSK-installer.exe The onscreen keyboard looks fine :) And more, it seems to not need the compatibility to W8 setted, I have to reboot W10 to make sure but looks great :) Thanks Pere > > Step by step .... > > -- > Shin-ichi > > TOYAMA Shin-ichi wrote in <616a170e.4969%sh...@wm...> > > Thanks Pere! > > > > Then I should get all the mtw() staff back and dig into the > > deep. > > > > I will focus on Onscreen Keyboard at first. > > I am wondering if it might be worth trying to directly use > > mbstowcs_s() on Windows to avoid using iconv(). > > > > https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/mbstowcs-s-mbstowcs-s-l?view=msvc-160 > > > > Hrm... > > > > Pere Pujal i Carabantes wrote in > > <b7c...@gm...> > > > Hi, > > > > > > El dv. 15 de 10 de 2021 a les 13:43 +0900, en/na TOYAMA Shin-ichi va escriure: > > > > Hi, > > > > > > > > I strongly hope this will be a final report. > > > > > > > > Here is a brief (long?) history; > > > > > > > > 1) OSK crash regarding libiconv reported in, > > > > https://sourceforge.net/p/tuxpaint/bugs/235/ > > > > 2) Win32 specific codes mtw() using iconv(), alternative to > > > > mbstowcs(), were removed and once seemed to work fine. > > > > 3) Found that it still crash only on Windows10 and later. > > > > 4) Trial to sepalate mtw() to single lib failed. > > > > 5) Found that it crash not when using OSK, but when loading > > > > labels embedded in png drowings. > > > > > > > > At this point, I remember that Bill mentiond that iconv() is > > > > also used in do_png_embed_data() in bugs/235 above. > > > > > > > > Then, I also removed "#ifdef WIN32" part in this function, and > > > > it seems to work quite fine! > > > > > > > > Patch to 0.9.26 is attached and binary packages are available > > > > from, > > > > > > > > https://z1.plala.jp/tuxpaint/release/0.9.26-4/ > > > > > > I am sorry to say it still doesn't work fine with labels, > > > it seems to work fine if the drawing stays in Windows, but when you > > > import/export a drawing between Linux and Windows then there are > > > problems. > > > > > > I've made a drawing in Linux (800x600) with all the strings duplicated, > > > once as text and again as labels, you could get it at > > > https://provant.freeddns.org/pere/public_html/developing/20211015/20211015205933.png > > > > > > See how only the first label string, made with the plain abcd row > > > of the onscreen keyboard is displayed in 0.9.26-4, instead 0.9.26 > > > displays and edits all labels correctly(both with compatibility > > > mode activated in W10). > > > > > > > > > > > > > By the way, I am quite at a loss what for those WIN32 specific > > > > code were needed, because patched code also compiled on the old > > > > mingw/msys environment and works fine on Windows XP just by > > > > defining lacking strtok_r() in onscreen_keyboard.c as follows. > > > > > > > > #define strtok_r(line, delim, pointer) strtok(line, delim) > > > > > > > > I am not sure but those code might have been tweaked when > > > > compiling in older build environment. > > > > > > I really don't know, I remember struggling and testing tons of things > > > until found something that seemed to make labels compatible > > > between Linux and Windows, not sure if we are talking about the same code. > > > > > > > > > Thanks > > > Pere > > > > > > > > > > Anyway, I think very carefull review and tests are required > > > > before releasing them. > > > > > > > > Hope your help! > > > > > > > > Thanks. > > > > > > > > > > > > TOYAMA Shin-ichi wrote in <6168e3c0.4965%sh...@wm...> > > > > > Just a brief report. > > > > > > > > > > Deleting mtw() seems to be OK. > > > > > > > > > > I found crash when loading drowing with labels occur in other > > > > > part. > > > > > > > > > > ------------------------------------------------------------ > > > > > Thread 1 received signal SIGSEGV, Segmentation fault. > > > > > 0x00007ffd86ab7f09 in msvcrt!memmove () from C:\WINDOWS\System32\msvcrt.dll > > > > > (gdb) backtrace > > > > > #0 0x00007ffd86ab7f09 in msvcrt!memmove () > > > > > from C:\WINDOWS\System32\msvcrt.dll > > > > > #1 0x00007ff6e502743e in load_embedded_data () > > > > > #2 0x00007ff6e50281f2 in load_current () > > > > > #3 0x00007ff6e5036842 in SDL_main () > > > > > #4 0x00007ff6e504461b in console_main () > > > > > #5 0x00007ff6e50446f8 in WinMain () > > > > > #6 0x00007ff6e50013b1 in __tmainCRTStartup () > > > > > at C:/_/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:321 > > > > > #7 0x00007ff6e50014c6 in WinMainCRTStartup () > > > > > at C:/_/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:176 > > > > > ------------------------------------------------------------ > > > > > > > > > > Thanks. > > > > > > > > > > TOYAMA Shin-ichi wrote in <61681fa6.4962%sh...@wm...> > > > > > > I was wrong again ;-< > > > > > > > > > > > > It crash when re-opening drawing with labels..... > > > > > > > > > > > > Sorry for the mess. > > > > > > > > > > > > > > > > > > TOYAMA Shin-ichi wrote in <61681264.4961%sh...@wm...> > > > > > > > Hi, > > > > > > > > > > > > > > It is becoming clear. > > > > > > > > > > > > > > I suppose it was wrong to delete WIN32 specific code in > > > > > > > load_info_about_label_surface() function for 0.9.26-2. > > > > > > > > > > > > > > Pere Pujal i Carabantes wrote in > > > > > > > <693...@gm...> > > > > > > > > Unfortunately msys mbstowcs() seems not work outside ascii :( > > > > > > > > > > > > > > Because I am not so sure about this, I removed mtw() from > > > > > > > onscreen_keyboard.c and tuxpaint.c again and just replaced mtw() > > > > > > > in the label function with mbstowcs() not deleting all the > > > > > > > windows specific part. > > > > > > > > > > > > > > It seems to work fine for me. > > > > > > > No crash, rapid osk layout change and no problem when using labels > > > > > > > and osk with Japanese characters! > > > > > > > > > > > > > > Could you please give a try to 0.9.26-3 packages in > > > > > > > > > > > > > > https://z1.plala.jp/tuxpaint/release/0.9.26-3/ > > > > > > > > > > > > > > If they are fine also for you, I will commit the changes to the > > > > > > > git repo. > > > > > > > > > > > > > > Thanks! > > > > > > > > _______________________________________________ > > > > 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 > > _______________________________________________ > Tuxpaint-devel mailing list > Tux...@li... > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel |
|
From: Bill K. <nb...@so...> - 2021-10-17 08:04:29
|
On Sun, Oct 17, 2021 at 12:01:51AM -0700, Bill Kendrick wrote: > On Sat, Oct 16, 2021 at 04:15:39PM +0200, Pere Pujal i Carabantes wrote: > <snip> > > As far as I've tested it works fine in W10: > > No need to enable compatibility to W8 to make it running. > > No crashes with labels. > > No crashes with onscreen keyboard. > > Drawings can be exported/imported from/to Linux/Windows withouth labels being corrupted. > > > > BIG THANKS :) > > Big thanks indeed!!! Sorry I haven't been helping more; while I have > (limited ;) ) access to my kids' Windows laptops, I don't yet have > any development stuff installed on either of them. Also, I've been > knocked out a bit due to a wisdom tooth that needs removal. X^[ > > So I'm very glad you all were able to sort it out! Thanks again, Hum, so I installed 0.9.26-5 via the installer EXE, but when I launch it, nothing happens. No window appears at all. I tried using the "troubleshoot compatibility" option, and it suggested Windows 8 mode, but running the test did nothing. I tried running as administrator, and I saw "stderr" and "stdout" files appear in C:\Program Files (x86)\TuxPaint, but they are both empty. I tried uninstalling and re-installing completely (vs. installing over the existing version), but that didn't help. I tried moving the "TuxPaint" folder in C:\Users\USERNAME\AppData\Roaming\ out of the way (renamed to "TuxPaintXYZ") and launching again. Tux Paint got as far as creating a new "TuxPaint" folder in there, but Settings -> System -> About says it's a 64-bit OS, with x64-based processor. Windows 10 Home, version 20H2, OS Build 19042.1288, with Windows Features Experience Pack 120.2212.3920.0. I WAS able to get the i686 32-bit version to install and run. So, yikes, this might not be working properly, still!? -- -bill! Sent from my computer |
|
From: TOYAMA Shin-i. <sh...@wm...> - 2021-10-17 08:27:35
|
So bad... I am almost exhousted. Sorry about that, but please give me some more time. Bill Kendrick wrote in <202...@sh...> >Hum, so I installed 0.9.26-5 via the installer EXE, but when I launch it, >nothing happens. No window appears at all. I tried using the >"troubleshoot compatibility" option, and it suggested Windows 8 mode, >but running the test did nothing. I tried running as administrator, >and I saw "stderr" and "stdout" files appear in C:\Program Files (x86)\TuxPaint, >but they are both empty. > >I tried uninstalling and re-installing completely (vs. installing over >the existing version), but that didn't help. > >I tried moving the "TuxPaint" folder in C:\Users\USERNAME\AppData\Roaming\ >out of the way (renamed to "TuxPaintXYZ") and launching again. >Tux Paint got as far as creating a new "TuxPaint" folder in there, but > >Settings -> System -> About says it's a 64-bit OS, with x64-based processor. >Windows 10 Home, version 20H2, OS Build 19042.1288, with Windows Features >Experience Pack 120.2212.3920.0. > >I WAS able to get the i686 32-bit version to install and run. > >So, yikes, this might not be working properly, still!? -- TOYAMA Shin-ichi mailto:sh...@wm... |
|
From: Pere P. i C. <per...@gm...> - 2021-10-17 11:59:35
|
El dg. 17 de 10 de 2021 a les 01:04 -0700, en/na Bill Kendrick va escriure: > On Sun, Oct 17, 2021 at 12:01:51AM -0700, Bill Kendrick wrote: > > On Sat, Oct 16, 2021 at 04:15:39PM +0200, Pere Pujal i Carabantes wrote: > > <snip> > > > As far as I've tested it works fine in W10: > > > No need to enable compatibility to W8 to make it running. > > > No crashes with labels. > > > No crashes with onscreen keyboard. > > > Drawings can be exported/imported from/to Linux/Windows withouth labels being corrupted. > > > > > > BIG THANKS :) > > > > Big thanks indeed!!! Sorry I haven't been helping more; while I have > > (limited ;) ) access to my kids' Windows laptops, I don't yet have > > any development stuff installed on either of them. Also, I've been > > knocked out a bit due to a wisdom tooth that needs removal. X^[ > > > > So I'm very glad you all were able to sort it out! Thanks again, > > Hum, so I installed 0.9.26-5 via the installer EXE, but when I launch it, > nothing happens. No window appears at all. I tried using the > "troubleshoot compatibility" option, and it suggested Windows 8 mode, > but running the test did nothing. I tried running as administrator, > and I saw "stderr" and "stdout" files appear in C:\Program Files (x86)\TuxPaint, > but they are both empty. > > I tried uninstalling and re-installing completely (vs. installing over > the existing version), but that didn't help. > > I tried moving the "TuxPaint" folder in C:\Users\USERNAME\AppData\Roaming\ > out of the way (renamed to "TuxPaintXYZ") and launching again. > Tux Paint got as far as creating a new "TuxPaint" folder in there, but > > Settings -> System -> About says it's a 64-bit OS, with x64-based processor. > Windows 10 Home, version 20H2, OS Build 19042.1288, with Windows Features > Experience Pack 120.2212.3920.0. > > I WAS able to get the i686 32-bit version to install and run. > > So, yikes, this might not be working properly, still!? > Did you by chance install 0.9.26-5 64bit just to current user or to all users? I've just found stalled direct accesses on the screen who still points to C:\Program Files (x86)\TuxPaint when, if installed to current user, Tux Paint is in C:\Users\USERNAME\Programs\TuxPaint. Or maybe the inverse? Otherwise, Tux Paint runs fine here, This is in an vboxed W10 Edición Windows 10 Home Versión 20H2 Instalado el 28/12/2020 Compilación del sistema operativo 19042.1237 Experiencia Windows Feature Experience Pack 120.2212.3530.0 |
|
From: TOYAMA Shin-i. <sh...@wm...> - 2021-10-24 12:24:08
|
Bill Kendrick wrote in <202...@sh...> >Hum, so I installed 0.9.26-5 via the installer EXE, but when I launch it, >nothing happens. No window appears at all. It reproduced by lounching TuxPaint from anoter user who does not have administrator priviledge. I will have to look into it. -- TOYAMA Shin-ichi mailto:sh...@wm... |
|
From: TOYAMA Shin-i. <sh...@wm...> - 2021-10-24 15:47:58
|
Well, I may have found a clue. It had nothing to do with the priviledges. The problem is that 64bit version runs on my account and does not run on the other user's account. Difference between two users were environmental variable. I have set 'LANG' environmet variable as ja_JP.UTF-8 and LANG has not been set on the other user's account. Then, I tested 64bit package by unsetting 'LANG' on my account, and found it does not start. (Strangely 32 bit version starts with no problem....) The worse is that this problem has nothing to do with the recent changes in source code, but seems to related with some change in tha latest MinGW/MSYS environment, because now I never be able to build 64bit package which runs on the other account even using original tar-ball of version 0.9.26. You see the first release of 64bit 0.9.26 does not have this problem. (Although it has crash bug regarding osk and label) Bill, Could you test on your son's PC to set LANG to "C" or something in "advanced system properties" dialogue? http://www.tenuser.com/spec/properties.htm (you need to sign out and sign in again after changin system properties) TOYAMA Shin-ichi wrote in <6175505b.4994%sh...@wm...> >Bill Kendrick wrote in <202...@sh...> >>Hum, so I installed 0.9.26-5 via the installer EXE, but when I launch it, >>nothing happens. No window appears at all. > >It reproduced by lounching TuxPaint from anoter user who does not >have administrator priviledge. > >I will have to look into it. -- TOYAMA Shin-ichi mailto:sh...@wm... |
|
From: Bill K. <nb...@so...> - 2021-10-26 05:48:24
|
On Tue, Oct 26, 2021 at 12:23:45AM +0900, TOYAMA Shin-ichi wrote: > Hi developpers, > > At first, please take note that the problem is that 64bit > executable for windows crash when it start unless specific locale > is set by config/command line option/environment variable. > > I found that the crash occurs in mysetenv() in i18n.c when > strlen(value) is called. This probably won't "fix" the overall issue that's causing the crash, but I've updated mysetenv() to be lest trusting of its incoming arguments. If either `name` and/or `value` is NULL, it will avoid doing anything dangerous with them, and spit out a warning to STDERR. https://sourceforge.net/p/tuxpaint/tuxpaint/ci/1bee12246eedd6ddc4790bb5dacdec6b50685a6e/ -bill! |
|
From: TOYAMA Shin-i. <sh...@wm...> - 2021-10-26 15:07:47
|
Thanks bill, I think it is fixed. What I did was, again, to simply remove the windows-specific parts in which _nl_locale_name() is called. I committed it to the git and prepared 0.9.26-6 packages although I am not sure if it is neccesary. https://z1.plala.jp/tuxpaint/release/0.9.26-6/ In these days, multiple bugs on ｗindows build unrelated to each other have become apparent, causing a lot of confusion, but I hope this will settle things down for a while ;-). Thanks, Bill Kendrick wrote in <202...@sh...> >On Tue, Oct 26, 2021 at 12:23:45AM +0900, TOYAMA Shin-ichi wrote: >> Hi developpers, >> >> At first, please take note that the problem is that 64bit >> executable for windows crash when it start unless specific locale >> is set by config/command line option/environment variable. >> >> I found that the crash occurs in mysetenv() in i18n.c when >> strlen(value) is called. > >This probably won't "fix" the overall issue that's causing >the crash, but I've updated mysetenv() to be lest trusting of >its incoming arguments. If either `name` and/or `value` is NULL, >it will avoid doing anything dangerous with them, and spit out >a warning to STDERR. > > >https://sourceforge.net/p/tuxpaint/tuxpaint/ci/1bee12246eedd6ddc4790bb5dacdec6b50685a6e/ > >-bill! -- TOYAMA Shin-ichi mailto:sh...@wm... |
|
From: Bill K. <nb...@so...> - 2021-10-26 18:03:10
|
On Tue, Oct 26, 2021 at 11:43:34PM +0900, TOYAMA Shin-ichi wrote: > Thanks bill, > > I think it is fixed. > What I did was, again, to simply remove the windows-specific > parts in which _nl_locale_name() is called. Great! (And thanks for noting my late-night #ifdef typo) > I committed it to the git and prepared 0.9.26-6 packages although > I am not sure if it is neccesary. > > https://z1.plala.jp/tuxpaint/release/0.9.26-6/ Fetching, and will post to SourceForge. > In these days, multiple bugs on $B#w(Bindows build unrelated to each Heh, in Mutt mail client your "W" came out as a bunch of crazy ASCII, so it looked like you were cursing Windows. I guess Emacs editor is better at rendering it. > other have become apparent, causing a lot of confusion, but I hope > this will settle things down for a while ;-). Yes, thanks so much for toiling over this. And thanks again to Pere and others for helping, as well! 6th time's the charm? -bill! > > Thanks, > > > Bill Kendrick wrote in <202...@sh...> > >On Tue, Oct 26, 2021 at 12:23:45AM +0900, TOYAMA Shin-ichi wrote: > >> Hi developpers, > >> > >> At first, please take note that the problem is that 64bit > >> executable for windows crash when it start unless specific locale > >> is set by config/command line option/environment variable. > >> > >> I found that the crash occurs in mysetenv() in i18n.c when > >> strlen(value) is called. > > > >This probably won't "fix" the overall issue that's causing > >the crash, but I've updated mysetenv() to be lest trusting of > >its incoming arguments. If either `name` and/or `value` is NULL, > >it will avoid doing anything dangerous with them, and spit out > >a warning to STDERR. > > > > > >https://sourceforge.net/p/tuxpaint/tuxpaint/ci/1bee12246eedd6ddc4790bb5dacdec6b50685a6e/ > > > >-bill! > > -- > TOYAMA Shin-ichi mailto:sh...@wm... -- -bill! Sent from my computer |
|
From: TOYAMA Shin-i. <sh...@wm...> - 2021-10-24 15:54:04
|
By the way, workaround for this is to set language to something other than (Use system's setting) by tuxpaint-config, so far. TOYAMA Shin-ichi wrote in <61758024.4995%sh...@wm...> >Well, I may have found a clue. >It had nothing to do with the priviledges. > >The problem is that 64bit version runs on my account and does not >run on the other user's account. > >Difference between two users were environmental variable. >I have set 'LANG' environmet variable as ja_JP.UTF-8 and LANG has >not been set on the other user's account. > >Then, I tested 64bit package by unsetting 'LANG' on my account, >and found it does not start. (Strangely 32 bit version starts with >no problem....) > >The worse is that this problem has nothing to do with the recent >changes in source code, but seems to related with some change in >tha latest MinGW/MSYS environment, because now I never be able to >build 64bit package which runs on the other account even using >original tar-ball of version 0.9.26. > >You see the first release of 64bit 0.9.26 does not have this >problem. (Although it has crash bug regarding osk and label) > >Bill, > >Could you test on your son's PC to set LANG to "C" or something in >"advanced system properties" dialogue? > > http://www.tenuser.com/spec/properties.htm > >(you need to sign out and sign in again after changin system properties) > > > >TOYAMA Shin-ichi wrote in <6175505b.4994%sh...@wm...> >>Bill Kendrick wrote in <202...@sh...> >>>Hum, so I installed 0.9.26-5 via the installer EXE, but when I launch it, >>>nothing happens. No window appears at all. >> >>It reproduced by lounching TuxPaint from anoter user who does not >>have administrator priviledge. >> >>I will have to look into it. -- TOYAMA Shin-ichi mailto:sh...@wm... |
|
From: Bill K. <nb...@so...> - 2021-10-25 05:25:18
|
On Mon, Oct 25, 2021 at 12:53:48AM +0900, TOYAMA Shin-ichi wrote: > By the way, workaround for this is to set language to something > other than (Use system's setting) by tuxpaint-config, so far. Very interesting! Thanks, Shin-ichi. I had a person email me this evening mentioning TP won't start on their new Win11 system, so I've suggested this work-around. (I'll let you know if they tell me that it _didn't_ help :) ) -bill! > > TOYAMA Shin-ichi wrote in <61758024.4995%sh...@wm...> > >Well, I may have found a clue. > >It had nothing to do with the priviledges. > > > >The problem is that 64bit version runs on my account and does not > >run on the other user's account. > > > >Difference between two users were environmental variable. > >I have set 'LANG' environmet variable as ja_JP.UTF-8 and LANG has > >not been set on the other user's account. > > > >Then, I tested 64bit package by unsetting 'LANG' on my account, > >and found it does not start. (Strangely 32 bit version starts with > >no problem....) > > > >The worse is that this problem has nothing to do with the recent > >changes in source code, but seems to related with some change in > >tha latest MinGW/MSYS environment, because now I never be able to > >build 64bit package which runs on the other account even using > >original tar-ball of version 0.9.26. > > > >You see the first release of 64bit 0.9.26 does not have this > >problem. (Although it has crash bug regarding osk and label) > > > >Bill, > > > >Could you test on your son's PC to set LANG to "C" or something in > >"advanced system properties" dialogue? > > > > http://www.tenuser.com/spec/properties.htm > > > >(you need to sign out and sign in again after changin system properties) > > > > > > > >TOYAMA Shin-ichi wrote in <6175505b.4994%sh...@wm...> > >>Bill Kendrick wrote in <202...@sh...> > >>>Hum, so I installed 0.9.26-5 via the installer EXE, but when I launch it, > >>>nothing happens. No window appears at all. > >> > >>It reproduced by lounching TuxPaint from anoter user who does not > >>have administrator priviledge. > >> > >>I will have to look into it. > > -- > 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-25 15:23:58
|
Hi developpers,
At first, please take note that the problem is that 64bit
executable for windows crash when it start unless specific locale
is set by config/command line option/environment variable.
I found that the crash occurs in mysetenv() in i18n.c when
strlen(value) is called.
The address of the string 'value' is passed from 'loc' which is
set by calling _nl_locale_name() in set_current_language().
I checked the return value 'loc' from _nl_locale_name() by;
printf("%s", loc);
It results "ja_JP" on 32bit executable but, crash occurs on 64bit
version.
I am quite at a loss how I should do so far.
Anyway, I think it would be better to stop releasing the 64bit
version until this will be fixed.
Thanks.
Bill Kendrick wrote in <202...@sh...>
>On Mon, Oct 25, 2021 at 12:53:48AM +0900, TOYAMA Shin-ichi wrote:
>> By the way, workaround for this is to set language to something
>> other than (Use system's setting) by tuxpaint-config, so far.
>
>Very interesting! Thanks, Shin-ichi. I had a person email me
>this evening mentioning TP won't start on their new Win11 system,
>so I've suggested this work-around. (I'll let you know if they
>tell me that it _didn't_ help :) )
>
>-bill!
>
>
>>
>> TOYAMA Shin-ichi wrote in <61758024.4995%sh...@wm...>
>> >Well, I may have found a clue.
>> >It had nothing to do with the priviledges.
>> >
>> >The problem is that 64bit version runs on my account and does not
>> >run on the other user's account.
>> >
>> >Difference between two users were environmental variable.
>> >I have set 'LANG' environmet variable as ja_JP.UTF-8 and LANG has
>> >not been set on the other user's account.
>> >
>> >Then, I tested 64bit package by unsetting 'LANG' on my account,
>> >and found it does not start. (Strangely 32 bit version starts with
>> >no problem....)
>> >
>> >The worse is that this problem has nothing to do with the recent
>> >changes in source code, but seems to related with some change in
>> >tha latest MinGW/MSYS environment, because now I never be able to
>> >build 64bit package which runs on the other account even using
>> >original tar-ball of version 0.9.26.
>> >
>> >You see the first release of 64bit 0.9.26 does not have this
>> >problem. (Although it has crash bug regarding osk and label)
>> >
>> >Bill,
>> >
>> >Could you test on your son's PC to set LANG to "C" or something in
>> >"advanced system properties" dialogue?
>> >
>> > http://www.tenuser.com/spec/properties.htm
>> >
>> >(you need to sign out and sign in again after changin system properties)
>> >
>> >
>> >
>> >TOYAMA Shin-ichi wrote in <6175505b.4994%sh...@wm...>
>> >>Bill Kendrick wrote in <202...@sh...>
>> >>>Hum, so I installed 0.9.26-5 via the installer EXE, but when I launch it,
>> >>>nothing happens. No window appears at all.
>> >>
>> >>It reproduced by lounching TuxPaint from anoter user who does not
>> >>have administrator priviledge.
>> >>
>> >>I will have to look into it.
>>
>> --
>> TOYAMA Shin-ichi mailto:sh...@wm...
>>
>>
>> _______________________________________________
>> Tuxpaint-devel mailing list
>> Tux...@li...
>> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
--
TOYAMA Shin-ichi mailto:sh...@wm...
|
|
From: Mark K. K. <mar...@gm...> - 2021-10-25 17:30:16
|
> I found that the crash occurs in mysetenv() in i18n.c when
> strlen(value) is called.
I'm not sure if it's related, but getenv/putenv are known to be not
thread-safe, and we do use them liberally and do use threads at
initialization.
On Mon, Oct 25, 2021 at 11:24 AM TOYAMA Shin-ichi <sh...@wm...>
wrote:
> Hi developpers,
>
> At first, please take note that the problem is that 64bit
> executable for windows crash when it start unless specific locale
> is set by config/command line option/environment variable.
>
> I found that the crash occurs in mysetenv() in i18n.c when
> strlen(value) is called.
>
> The address of the string 'value' is passed from 'loc' which is
> set by calling _nl_locale_name() in set_current_language().
>
> I checked the return value 'loc' from _nl_locale_name() by;
>
> printf("%s", loc);
>
> It results "ja_JP" on 32bit executable but, crash occurs on 64bit
> version.
>
> I am quite at a loss how I should do so far.
>
> Anyway, I think it would be better to stop releasing the 64bit
> version until this will be fixed.
>
> Thanks.
>
> Bill Kendrick wrote in <202...@sh...>
> >On Mon, Oct 25, 2021 at 12:53:48AM +0900, TOYAMA Shin-ichi wrote:
> >> By the way, workaround for this is to set language to something
> >> other than (Use system's setting) by tuxpaint-config, so far.
> >
> >Very interesting! Thanks, Shin-ichi. I had a person email me
> >this evening mentioning TP won't start on their new Win11 system,
> >so I've suggested this work-around. (I'll let you know if they
> >tell me that it _didn't_ help :) )
> >
> >-bill!
> >
> >
> >>
> >> TOYAMA Shin-ichi wrote in <61758024.4995%sh...@wm...>
> >> >Well, I may have found a clue.
> >> >It had nothing to do with the priviledges.
> >> >
> >> >The problem is that 64bit version runs on my account and does not
> >> >run on the other user's account.
> >> >
> >> >Difference between two users were environmental variable.
> >> >I have set 'LANG' environmet variable as ja_JP.UTF-8 and LANG has
> >> >not been set on the other user's account.
> >> >
> >> >Then, I tested 64bit package by unsetting 'LANG' on my account,
> >> >and found it does not start. (Strangely 32 bit version starts with
> >> >no problem....)
> >> >
> >> >The worse is that this problem has nothing to do with the recent
> >> >changes in source code, but seems to related with some change in
> >> >tha latest MinGW/MSYS environment, because now I never be able to
> >> >build 64bit package which runs on the other account even using
> >> >original tar-ball of version 0.9.26.
> >> >
> >> >You see the first release of 64bit 0.9.26 does not have this
> >> >problem. (Although it has crash bug regarding osk and label)
> >> >
> >> >Bill,
> >> >
> >> >Could you test on your son's PC to set LANG to "C" or something in
> >> >"advanced system properties" dialogue?
> >> >
> >> > http://www.tenuser.com/spec/properties.htm
> >> >
> >> >(you need to sign out and sign in again after changin system
> properties)
> >> >
> >> >
> >> >
> >> >TOYAMA Shin-ichi wrote in <6175505b.4994%sh...@wm...>
> >> >>Bill Kendrick wrote in <202...@sh...>
> >> >>>Hum, so I installed 0.9.26-5 via the installer EXE, but when I
> launch it,
> >> >>>nothing happens. No window appears at all.
> >> >>
> >> >>It reproduced by lounching TuxPaint from anoter user who does not
> >> >>have administrator priviledge.
> >> >>
> >> >>I will have to look into it.
> >>
> >> --
> >> TOYAMA Shin-ichi mailto:sh...@wm...
> >>
> >>
> >> _______________________________________________
> >> 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
>
|
|
From: Bill K. <nb...@so...> - 2021-10-26 10:08:23
|
On Mon, Oct 25, 2021 at 01:30:01PM -0400, Mark K. Kim wrote:
> > I found that the crash occurs in mysetenv() in i18n.c when
> > strlen(value) is called.
>
> I'm not sure if it's related, but getenv/putenv are known to be not
> thread-safe, and we do use them liberally and do use threads at
> initialization.
Well here it sounds like `value` is coming back as NULL or garbage,
hence Shin-ichi's `printf("%s", loc);` also crashing.
The place where `_nl_locale_name()` is called is within `i18n.c`'s
`set_current_language()` function, which in turn is called by that
same source file's `setup_i18n()` function.
`setup_i18n` is called, in `tuxpaint.c`, within `setup_config()`.
This gets called in `main()` _before_ our own threading stuff happens
("FORKED_FONTS").
So I don't think that's the issue...
Shin-ichi, I wonder if it'd be sufficient to just check whether
`_nl_locale_name()` returns NULL. If so, we can set `loc` to "C",
like so (maybe? I'm struggling to remember how all this works):
...
#ifdef _WIN32
if (!*loc) {
loc = _nl_locale_name(LC_MESSAGES, "");
if (loc == NULL) {
loc = strdup("C");
}
}
#else
...
-bill!
> On Mon, Oct 25, 2021 at 11:24 AM TOYAMA Shin-ichi <sh...@wm...>
> wrote:
>
> > Hi developpers,
> >
> > At first, please take note that the problem is that 64bit
> > executable for windows crash when it start unless specific locale
> > is set by config/command line option/environment variable.
> >
> > I found that the crash occurs in mysetenv() in i18n.c when
> > strlen(value) is called.
> >
> > The address of the string 'value' is passed from 'loc' which is
> > set by calling _nl_locale_name() in set_current_language().
> >
> > I checked the return value 'loc' from _nl_locale_name() by;
> >
> > printf("%s", loc);
> >
> > It results "ja_JP" on 32bit executable but, crash occurs on 64bit
> > version.
> >
> > I am quite at a loss how I should do so far.
> >
> > Anyway, I think it would be better to stop releasing the 64bit
> > version until this will be fixed.
> >
> > Thanks.
> >
> > Bill Kendrick wrote in <202...@sh...>
> > >On Mon, Oct 25, 2021 at 12:53:48AM +0900, TOYAMA Shin-ichi wrote:
> > >> By the way, workaround for this is to set language to something
> > >> other than (Use system's setting) by tuxpaint-config, so far.
> > >
> > >Very interesting! Thanks, Shin-ichi. I had a person email me
> > >this evening mentioning TP won't start on their new Win11 system,
> > >so I've suggested this work-around. (I'll let you know if they
> > >tell me that it _didn't_ help :) )
> > >
> > >-bill!
> > >
> > >
> > >>
> > >> TOYAMA Shin-ichi wrote in <61758024.4995%sh...@wm...>
> > >> >Well, I may have found a clue.
> > >> >It had nothing to do with the priviledges.
> > >> >
> > >> >The problem is that 64bit version runs on my account and does not
> > >> >run on the other user's account.
> > >> >
> > >> >Difference between two users were environmental variable.
> > >> >I have set 'LANG' environmet variable as ja_JP.UTF-8 and LANG has
> > >> >not been set on the other user's account.
> > >> >
> > >> >Then, I tested 64bit package by unsetting 'LANG' on my account,
> > >> >and found it does not start. (Strangely 32 bit version starts with
> > >> >no problem....)
> > >> >
> > >> >The worse is that this problem has nothing to do with the recent
> > >> >changes in source code, but seems to related with some change in
> > >> >tha latest MinGW/MSYS environment, because now I never be able to
> > >> >build 64bit package which runs on the other account even using
> > >> >original tar-ball of version 0.9.26.
> > >> >
> > >> >You see the first release of 64bit 0.9.26 does not have this
> > >> >problem. (Although it has crash bug regarding osk and label)
> > >> >
> > >> >Bill,
> > >> >
> > >> >Could you test on your son's PC to set LANG to "C" or something in
> > >> >"advanced system properties" dialogue?
> > >> >
> > >> > http://www.tenuser.com/spec/properties.htm
> > >> >
> > >> >(you need to sign out and sign in again after changin system
> > properties)
> > >> >
> > >> >
> > >> >
> > >> >TOYAMA Shin-ichi wrote in <6175505b.4994%sh...@wm...>
> > >> >>Bill Kendrick wrote in <202...@sh...>
> > >> >>>Hum, so I installed 0.9.26-5 via the installer EXE, but when I
> > launch it,
> > >> >>>nothing happens. No window appears at all.
> > >> >>
> > >> >>It reproduced by lounching TuxPaint from anoter user who does not
> > >> >>have administrator priviledge.
> > >> >>
> > >> >>I will have to look into it.
> > >>
> > >> --
> > >> TOYAMA Shin-ichi mailto:sh...@wm...
> > >>
> > >>
> > >> _______________________________________________
> > >> 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-17 08:20:12
|
Hi,
I investigated more to understand why this happened by checking
original 0.9.26's code.
In old build system for Windows 2000/XP,
----------------
msys:$ make obj/onscreen_keyboard.o
...Compiling on screen keyboard support...
msys:$
----------------
You see no warning and no error.
However, in the latest MinGW/MSYS2 build environment,
----------------
mingw64:$ make obj/onscreen_keyboard.o
...Compiling on screen keyboard support...
src/onscreen_keyboard.c: In function 'mtw':
src/onscreen_keyboard.c:76:16: warning: passing argument 2 of 'libiconv' from
incompatible pointer type [-Wincompatible-pointer-types]
76 | iconv(trans, (const char **)&tok, &in, &wrptr, &out);
| ^~~~~~~~~~~~~~~~~~~
| |
| const char **
In file included from src/onscreen_keyboard.c:55:
C:/msys64/mingw64/include/iconv.h:82:43: note: expected 'char **' but argument
is of type 'const char **'
82 | extern size_t iconv (iconv_t cd, char* * inbuf, size_t *inbytesleft,
char* * outbuf, size_t *outbytesleft);
| ~~~~~~~~^~~~~
src/onscreen_keyboard.c:78:18: warning: passing argument 2 of 'swprintf' makes
integer from pointer without a cast [-Wint-conversion]
78 | swprintf(wtok, L"%ls", ui16);
| ^~~~~~
| |
| const short unsigned int *
In file included from C:/msys64/mingw64/x86_64-w64-mingw32/include/wchar.h:1192,
from src/onscreen_keyboard.h:1,
from src/onscreen_keyboard.c:23:
C:/msys64/mingw64/x86_64-w64-mingw32/include/swprintf.inl:34:41: note: expected
'size_t' {aka 'long long unsigned int'} but argument is of type 'const short
unsigned int *'
34 | int swprintf (wchar_t *__stream, size_t __count, const wchar_t
*__format, ...)
| ~~~~~~~^~~~~~~
src/onscreen_keyboard.c:66:10: warning: variable 'n' set but not used
[-Wunused-but-set-variable]
66 | size_t n, in, out;
| ^
mingw64:$
----------------
Interestingly, changing the second argument of 'swprintf()' to
the integer valiable results completely the opposite.
This result says that the type of second argument to swprintf()
becomes completely different in MinGW/MSYS2.
Although I am not sure why this works on Windows 8 and before,
it must be one of the reason for the crash on Windows10.
And you see another warning regarding iconv() which is now
unused in onscreen_keyboard.c but still used in tuxpaint.c
Until now, I have just ignored such warnings when compiling
TuxPaint on windows, but it might be better to look them more
carefully and try to reduce warnings as possible I can.
Thanks!
TOYAMA Shin-ichi wrote in
<616b70f2.4975%sh...@wm...>
>Hi Bill,
>
>Pere Pujal i Carabantes wrote in
><041...@gm...>
>>> Packages compiled as 0.9.26-5 are available in
>>>
>>> https://z1.plala.jp/tuxpaint/release/0.9.26-5/ (5!!)
>>>
>>> Could you give them final tests ?
>>> I pray that this will work out this time.
>>
>>As far as I've tested it works fine in W10:
>>No need to enable compatibility to W8 to make it running.
>>No crashes with labels.
>>No crashes with onscreen keyboard.
>>Drawings can be exported/imported from/to Linux/Windows without
>>labels being corrupted.
>
>So, I believe those two crash bug on windows10 have been fixed
>finally.
>
>By the way, patched 0.9.26 also compiled on the old build system
>for 2000 and XP, but it did not run.
>Then, I think that the initial tweak for windows on the OSK was
>not a mistake.
>
>I guess that this bug has been existing since when I changed the
>build system to MinGW/MSYS2 and become apparent in Windows10.
>
>I think every windows user, except XP/2000, would be suggested
>to upgrade to 0.9.26-5.
>
>Thanks.
--
TOYAMA Shin-ichi mailto:sh...@wm...
|
|
From: TOYAMA Shin-i. <sh...@wm...> - 2021-10-17 08:24:49
|
Hi,
TOYAMA Shin-ichi wrote in <616ba929.4976%sh...@wm...>
>Until now, I have just ignored such warnings when compiling
>TuxPaint on windows, but it might be better to look them more
>carefully and try to reduce warnings as possible I can.
So, I have overviewed many warnings when compiling on MinGW/MSYS.
Most of the warnings are,
* impllicit declaration
* unused variable
* variable xxx set but not used
* comparison of distinct pointer types lacks a cast
- which comes from macro min()/max() in tp_magic_api.h
I think these are not so harmful so far.
Then, I will show you other warnings which does not appear
when compiling on linux only for tuxpaint.c so far, for which
I am not sure if I could leave it as it is.
Escpecially the first one may break some important logic?
Please let me know if you find something I have to do.
------------------------------------------------------------
[1]
src/tuxpaint.c: In function 'render_text_w':
src/tuxpaint.c:1679:27: warning: comparison is always true due to limited range of data type [-Wtype-limits]
1679 | else if (str[i] <= 0x0000FFFF)
| ^~
[2]
src/tuxpaint.c: In function 'do_png_embed_data':
src/tuxpaint.c:14571:41: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
14571 | iconv(trans, (char **)&wch, &in, &conv, &out);
| ^~~~
[3]
src/tuxpaint.c: In function 'load_magic_plugins':
src/tuxpaint.c:19206:38: warning: assignment to 'Uint32 (*)(SDL_Surface *, int, int)' {aka 'unsigned int (*)(SDL_Surface *, int, int)'} from incompatible pointer type 'void (*)(SDL_Surface *, int, int)' [-Wincompatible-pointer-types]
19206 | magic_api_struct->xorpixel = magic_xorpixel;
| ^
[4]
src/tuxpaint.c: In function 'trash':
src/tuxpaint.c:25956:40: warning: unknown conversion type character 'F' in format [-Wformat=]
25956 | strftime(deldate, sizeof(deldate), "%FT%T", &tim);
| ^
src/tuxpaint.c:25956:43: warning: unknown conversion type character 'T' in format [-Wformat=]
25956 | strftime(deldate, sizeof(deldate), "%FT%T", &tim);
| ^
[5]
In function 'safe_strncpy',
inlined from 'trash' at src/tuxpaint.c:25883:3:
src/tuxpaint.c:26820:9: warning: 'strncpy' output may be truncated copying 255 bytes from a string of length 255 [-Wstringop-truncation]
26820 | ptr = strncpy(dest, src, n - 1);
| ^~~~~~~~~~~~~~~~~~~~~~~~~
--
TOYAMA Shin-ichi mailto:sh...@wm...
|
×
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