[QtSerialPort] Simple example crashes
-
quickybr:
I also got strawberry perl, so i tried your way with Active Perl on the WinXp machine.
-> The QtSerialPort lib was compiled fine (same like with strawberry perl). I also could use it in Qt Creator but it didn't find any of my serial ports. I will check about this in detail tomorrow.Why WinXP machine and not the Win7 one iam actually working with?
-> i dont have admin on the win7 machine. I have to wait for the IT guys untill tomorrow.
:-/ -
bq. Removed the Perl that I was using (strawberry Perl)
Installed Active Perl (the last version)Hmm.. It is interesting, thx! May it is a cause of problem? Because I'm using Active perl and don't have a problem.
Can anyone try to check with this difference of Perl?
-
Yesterday I didn't have tried to communicate. But I tested now and I confirm, it's working properly
-
Hi everybody,
finally i got ActivePerl installed on the Win7 machine. Sadly it didn't change anything for me :-(. I compiled and installed QtSerialPort both ways: via console and via QtCreator and tested it.
The programm still crashes in the same behaviour as described before.
This is the crash track in detail:
main (QSerialPortInfo::availablePorts()) -> qserialportinfo_win.cpp;line 166 (QString s = devicePortName(deviceInfoSet, &deviceInfoData);) -> qserialportinfo_win.cpp;line 132 (QByteArray data(dataSize, 0);)The construction of the QByteArray fails somehow and this creates the Qt5Core.dll error. The question is why?
-
Hi,
okay i' one step further:
WinXP 32bit:
Status:
Couldn't find any serial ports but did not crash like Win7 Pro 64bit. QtSerialPort compiled with Strawberry Perl or ActivePerl didn't matter.Problem:
Administrator priviliges are needed otherwise "::SetupDiEnumDeviceInfo(deviceInfoSet, index++, &deviceInfoData)" returns true but the &deviceInfoData is emtpy respectivly the device name is empty (QString s = devicePortName(deviceInfoSet, &deviceInfoData))I'll try to get administrator priviliges tomorrow to try this on Windows7. At least i know how the serial ports are searched on windows systems.
Will this be changed? Otherwise users of my programm will also need administrator priviliges right? Wouldn't be that good.
-
bq. The question is why?
I don't know. For a solution I need to reproduce at itself crash - but I can't.
bq. Otherwise users of my programm will also need administrator priviliges right?
No. Privileges of the administrator aren't required. Most likely you have any other restrictions on your user account.
-
Hello everyone,
in the last weeks i had no time for further investigation about the error. Today i opened the example project again, ran it and it works! I Didn't change anything in the code and my priviliges on this machine are the same than i posted the last time.
I assume that in the time i didn't touch the project the IT department did a windows update via their updatemanagement that fixed my problem. I'll contact them for a list of updates they did in this time. I hope i get a list from them. Maybe i find a patch that could be related to my error.
I don't have any other explanation for this.
-
Similar issue.
Using QtSerialPort built from current 'stable' branch (50ab4d) causes simple example (from wiki) to crash in first QSerialPort::open() with segmentation fault (application terminates with exit code 255). Using QtSerialPort built from current 'release' branch (84df6e) works ok.
My setup is:
Win7 Pro x64
Qt 4.8.4 -
Bisecting between revisions I got following results:
- da0c6b works ok
- 43f7c6 seems works ok but adds messages to debug output: "virtual void QSerialPort::close(): device not open"
- 50ab4d causes crash (as described in previous post)
(Tests was performed by reusing full rebuild cycle: <module build dir> mingw32-make clean, <module build dir> mingw32-make uninstall, clean <module build dir>, clean <app project>, run qmake on <app project>, ...)
-
Hi.
Yes, I confirm it. Thx.
-
-
Yes, it fixed issue.
(But there are still warnings since 43f7c6. Seems like QSerialPort destructor tries to do some finalizing work on already closed port.) -
(But there are still warnings since 43f7c6. Seems like QSerialPort destructor tries to do some finalizing work on already closed port.)
It is a not problem.
-
@JBlackArty: