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 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...
-
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