Re: [Mingw-w64-public] std::regex freezes in Japanese locale

[Hannes Domani via Mingw-w64-public]

Am Samstag, 23. Januar 2021, 16:46:18 MEZ hat Jeroen Ooms  
Folgendes geschrieben:

> A user of the R programming language has reported that std::regex
> causes a hang for certain regular expressions when running in Japanese
> locale. I was able to reproduce this both with our production
> toolchain (mingw-w64 v5 + gcc 8) as well as the latest msys2
> toolchains.
>
> Is this a bug in mingw-w64 or elsewhere? Below a minimal example:
>
> #include 
> int main() {
>   setlocale(LC_ALL, "Japanese");
>   std::regex reg("[0-9]");
>   return 0;
> }

I can reproduce this as well, it took 108 seconds to finish here.

Deep in regex is this function:
std::__detail::_BracketMatcher, false, 
false>::_M_make_cache(std::integral_constant)

This caches transformed values of the unicode values 0-255 to the current
locale, with strxfrm_l [1].
This fails for a lot of them for japanese, and as documented, strxfrm_l
returns INT_MAX in this case.
But std::collate::do_transform does not handle any error case, it uses all
return values as the length of the transformed string.
And then it creates a copy of this 2GB string, which takes a lot of time,
around ~1s for each failing character.

It think this should be reported to gcc (libstdc++).


[1] 
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/strxfrm-wcsxfrm-strxfrm-l-wcsxfrm-l?view=msvc-160


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] new gdb build which can read/write windows minidump files

[Hannes Domani via Mingw-w64-public]

Hello


I've just uploaded a new gdb build on: https://github.com/ssbssa/gdb/releases

The most interesting added feature is that it can read windows minidump files 
(similar to how gdb handles core files on linux).

Any comments are welcome.


Regards
Domani Hannes


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [BUG (suspicious)] gdb crashes when info registers

[Hannes Domani via Mingw-w64-public]

> 在 2018/5/3 9:03, 章成凯 写道:
> > Sorry for that.
> > I upload the attachment to google drive and post the link in the bug report:
> > https://sourceforge.net/p/mingw-w64/bugs/731/

I'm pretty sure that it's this bug I reported a while ago:
https://sourceware.org/bugzilla/show_bug.cgi?id=22854

I also described a possible fix at the bottom, and using it, I have no crash 
with info registers.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] How to backtrace a crash with gdb on Windows 7

[Hannes Domani via Mingw-w64-public]

> (gdb) run
> Starting program: C:\_64\comp\mpfr_bug\ggdb\mpfr-4.0.0\tests\tfprintf.exe
> [New Thread 4680.0x160c]
> 
> This application has requested the Runtime to terminate it in an unusual
> way.
> Please contact the application's support team for more information.
> repl-vsnprintf.c:358: GNU MP assertion failed: 0
> [Inferior 1 (process 4680) exited with code 03]
> (gdb) bt
> No stack.

That's because it didn't crash, but an assertion failed.
This calls abort(), which then normally exits with exit code 3.

A crash looks in gdb like this:
Thread 1 received signal SIGSEGV, Segmentation fault.

To get a proper stacktrace for an assertion failure, just use "break abort"
before "run".


Regards
Hannes

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] swscanf() crashes if __USE_MINGW_ANSI_STDIO is defined

[Hannes Domani via Mingw-w64-public]

Am Samstag, 11. November 2017, 10:15:00 MEZ hat Liu Hao  
Folgendes geschrieben:

> Debugging in assembly exposes indirection through a null pointer in
> `mingw-w64-crt/stdio/mingw_wvfscanf.c` around or after line 906:
> 
> ```
> optimize_alloc ((flags & IS_ALLOC_USED) != 0, pstr, str_sz, (wstr -
> (wchar_t *) *pstr), sizeof (wchar_t));`
> ```

pstr==NULL, so the *pstr part crashes.

> The CRT libraries of those toolchains were not compiled with debug
> information. Further investigation might not be possible.
> 
> I am not able to reproducible this problem on master. You might want to
> try a newer version and see if the problem still exists.

It doesn't look fixed on master, mingw_wvfscanf.c is the same in v5.x and 
master.

But as far as I can tell this was fixed in mingw_vfscanf in here:
https://sourceforge.net/p/mingw-w64/mailman/message/27912175/
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/72d60c1a06490ec5937e6c620956b167bf0bf329/

There is even the suggestion that mingw_wvfscanf.c might need a similar fix, 
which was never done.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public