Autorelease pool page corrupted

SGaist

Can you test it with 4.8.6 ?

RogueWarrior

Okay, downloaded the Qt 4.8.6 Mac installer and ran it. Problem remains.
I've been experiencing other problems that are causing the Mac to lock up the mouse and keyboard while debugging a Qt program and I don't even have any breakpoints set. I have to do a force shutdown to bring it back.

MuldeR

I suggest you try creating the smallest possible program that can reproduce your issue. Quite often this will help to identify your own mistake. Otherwise, you can take resulting sample program and submit a bug report...

RogueWarrior

I'm also seeing a message in the Console output that usually appears when this problem rears its ugly head:

Example:
5/11/14 4:07:39.000 PM kernel[0]: gdb-i386-apple-d (map: 0xffffff802978d570) triggered DYLD shared region unnest for map: 0xffffff80295615c0, region 0x7fff8a200000->0x7fff8a400000. While not abnormal for debuggers, this increases system memory footprint until the target exits.

SGaist

Then you really should do what MuldeR suggested. It will help you identify the cause of this phenomenon

RogueWarrior

Well, it turns out that my real problem isn't Qt but rather the FTDI driver.

SGaist

Interesting… (but for other reasons) which version is it ?

RogueWarrior

It's the latest FTDI Mac driver, 2.2.18. As it turns out, when running at very high speeds e.g. 1 megabaud, if you don't keep up with the fire hose of data, it locks up the keyboard and the mouse. I contacted FTDI support about it and their response was essentially "Don't do that."

SGaist

So they provide a device + driver for high-speed serial communication and you shouldn't use it ?

RogueWarrior

Well, it's a generic driver and officially they only support standard serial (RS-232) baud rates. The chip itself can run up to 3 megabaud, IIRC. And there are no known problems with Linux or Windows drivers. When it comes to the Mac though, there is a procedure for modifying the Info.plist file in the driver kext file to "alias" a standard baud rate e.g. 300 to whatever rate you want. That works as long as you keep up with it which means don't even think of trying to set a break point in your code as long as the port is open.

FTDI acknowledges that there is a problem but unless you are an OEM that buys chips from them, they don't want to fix it.

SGaist

That's an interesting thing to know, thanks for sharing