Re: [Mingw-w64-public] setjmp/longjmp crashes, second setjmp argument

[lh_mouse]

Did `setjmp` macro take two parameters?

--   
lh_mouse
2015-09-29

-
发件人：Thomas Bickel 
发送日期：2015-09-28 23:15
收件人：mingw-w64-public
抄送：
主题：[Mingw-w64-public] setjmp/longjmp crashes, second setjmp argument

Hi everyone,

inspired by a posting here and because longjmp always crashed for me I 
investigated a bit and it 
seems the following is true:

If the second argument to setjmp is NULL longjmp will simply restore the 
register state and flags 
and resume program execution.
In fact this fixes all crashes for me, so I guess the second argument should 
always be NULL for C 
programs.

If the second argument to setjmp is not NULL longjmp will create and populate 
what looks like a 
EXCEPTION_RECORD structure on the stack, with ExceptionCode set to 
0x8026/STATUS_LONGJUMP.
This IMO strongly suggests that the second argument to setjmp should be a 
pointer to a CONTEXT 
structure.

see: 
https://msdn.microsoft.com/en-us/library/windows/desktop/ms680605%28v=vs.85%29.aspx


Running on Windows 10 Pro, gcc version 5.2.0 (x86_64-win32-sjlj-rev0, Built by 
MinGW-W64 project)


Regards,
Thomas

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



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

[Mingw-w64-public] Wrong definition of data type pid_t for 64 bit Windows?

[Stefan Weil]

Hi,

currently, Mingw-w64 defines pid_t to be an int on 32 bit Windows,
but __int64 on 64 bit Windows:

mingw-w64-headers/crt/sys/types.h:typedef int   _pid_t;
mingw-w64-headers/crt/sys/types.h:typedef __int64   _pid_t;
mingw-w64-headers/crt/sys/types.h:typedef _pid_tpid_t;

The relevant function getpid always return an int.
This return type and pid_t don't match on 64 bit Windows.

Are there good reasons why pid_t is not always an int for Windows?
Or should this be fixed in sys/types.h and also in
mingw-w64-libraries/winpthreads/include/pthread_compat.h?

Kind regards
Stefan Weil


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

Re: [Mingw-w64-public] Updates for usbioctl.h and usbspec.h

[Jacek Caban]

Hi David,

On 09/26/15 21:01, David Grayson wrote:
> This patch adds definitions, bit fields, and structs to USB header files that 
> are needed to compile the latest version of usbview from Microsoft on Github. 
>  (My previous patches were targeted at an older version of usbview.)
>
> Could someone apply this patch?  Thanks!

Your both patches look good to me. I committed them.

Thanks,
Jacek

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

[Mingw-w64-public] gcc-5.2 generating bad code in 32 bits ?

[renaud lepere]

I have a problem in the following code. It  crashed in 32bits in release 
only and works otherwise (64bits release), it seems that the stack 
return adress is corrupted.
I did not succed to remove the dependency to boost/utf since it does not 
crash if  BOOST_CHECK_CLOSE line is removed.
Also note, that if I replace the lambda with a normal function it works.

The same code was working with gcc-4.8-x but I upgraded to 5.2.0 and I 
have this problem.  The compiler is generating bad code ?
What can I do ?

#define BOOST_TEST_MODULE MyTest
#include 
#include 


struct P
{
 P(double x_, double y_): x(x_), y(y_) {}
 double x;
 double y;
};

struct Seg
{
 Seg(const P & o_, const P & e_): o(o_), e(e_) {}
 P o;
 P e;
};


void f()
{
 auto Check = [](const Seg & s1,
 bool dummy, double expected_length) {
 std::cerr << expected_length << std::endl;
 BOOST_CHECK_CLOSE(1e-3, 1e-4, .1);
 };
 Check(Seg(P(0, 0), P(100, 0)), false, 0.0);
 Check(Seg(P(0, 0), P(100, 0)), true, 100.0);
 std::cerr << "STILL LEAVING !" << std::endl;
}

void g()
{
 std::cerr << "BEFORE CRASH" << std::endl;
 f();
 std::cerr << "NEVER PRINTED" << std::endl;
}

BOOST_AUTO_TEST_CASE( my_test )
{
 g();
}


Extract from gcc -v
Target: i686-w64-mingw32
Thread model: posix
gcc version 5.2.0 (i686-posix-sjlj-rev0, Built by MinGW-W64 project)


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

[Mingw-w64-public] setjmp/longjmp crashes, second setjmp argument

[Thomas Bickel]

Hi everyone,

inspired by a posting here and because longjmp always crashed for me I 
investigated a bit and it 
seems the following is true:

If the second argument to setjmp is NULL longjmp will simply restore the 
register state and flags 
and resume program execution.
In fact this fixes all crashes for me, so I guess the second argument should 
always be NULL for C 
programs.

If the second argument to setjmp is not NULL longjmp will create and populate 
what looks like a 
EXCEPTION_RECORD structure on the stack, with ExceptionCode set to 
0x8026/STATUS_LONGJUMP.
This IMO strongly suggests that the second argument to setjmp should be a 
pointer to a CONTEXT 
structure.

see: 
https://msdn.microsoft.com/en-us/library/windows/desktop/ms680605%28v=vs.85%29.aspx


Running on Windows 10 Pro, gcc version 5.2.0 (x86_64-win32-sjlj-rev0, Built by 
MinGW-W64 project)


Regards,
Thomas

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

[Mingw-w64-public] CryptGetDefaultProvider

[Alexandre Pereira Nunes]

Is anyone able to compile and run the following example with mingw-w64?
https://msdn.microsoft.com/en-us/library/windows/desktop/aa379945(v=vs.85).aspx

It compiled for me, but complains at runtime about
CryptGetDefaultProviderA missing entry point.

It seems like mingw-64 defines the import lib for -lcrypt32, but this
function is actually defined in advapi32 .
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public