Autorelease pool page corrupted
-
I'm running Qt Creator 2.8.1 and Qt 4.8.5 on OSX 10.8.5 with a pretty basic console-type QSerialPort program.
I'm regularly seeing messages like:objc[1659]: autorelease pool page 0x103000000 corrupted
magic 0xa1a1a1a0 0x4f545541 0x454c4552 0x21455341
pthread 0x101581000After my code finishes and I've called
return a.exec(); -
Hi,
Are you only using Qt or are you also writing some native code ?
-
Nope. Strictly Qt.
-
Can you test it with 4.8.6 ?
-
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. -
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. -
Then you really should do what MuldeR suggested. It will help you identify the cause of this phenomenon
-
Well, it turns out that my real problem isn't Qt but rather the FTDI driver.
-
Interesting… (but for other reasons) which version is it ?
-
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."
-
So they provide a device + driver for high-speed serial communication and you shouldn't use it ?
-
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.
-
That's an interesting thing to know, thanks for sharing
