Important: Please read the Qt Code of Conduct -

QSerialPortInfo::availablePorts() freeze for ~30s

  • Dear Qt users,

    I recently changed the computer I am working on, and on the new system, every call to QSerialPortInfo::availablePorts() freeze the thread for about 30s, while it used to be instantaneous.
    Using the debugger, it seems to freeze in __lll_lock_wait_private or open64.
    If I run the application using sudo the same happens.
    It used to be working with pretty much the same versions of the kernel/Qt, so it's more of a system issue?

    Any idea of what could be the problem would be much appreciated.

    Some system information:
    vendor_id : GenuineIntel
    cpu family : 6
    model : 158
    model name : Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz
    stepping : 9
    microcode : 0x80

    4.14.14-1-MANJARO x86_64

    Selected software versions:
    glibc: 2.26
    gcc: 7.2.1 20171224
    Qt 5.10

  • Welcome @Hallot

    That's interesting, even though you might not have permission to access the ports, It should return really fast... Are you catching the QSerialPortInfo? What are you receiving in that QSerialPortInfo?

    Can you just that part of your code just to reference?

  • Hello Charlie, thanks for your quick answer.

    Yes, when I do not have permission, it is really fast, and it fails as expected.
    It's when I have the permission that I encounter the issue.
    What's interesting though is that after all the wait, I have the correct devices returned.

    It's really that QSerialPortInfo::availablePorts() line that is the issue.
    It also happens when I compile and run the "Enumerator example".

  • Lifetime Qt Champion

    Have you tested with non Qt serial app, how it reacts to scanning for ports?

  • It sounds that you have some issues with your new computer's port configuration. Which platform are you using?

    Anyway about the device that you want to connect by Serial... what is it?

  • @mrjj I have tried python -m but the output is wrong though immediate.
    Do you have an application in mind I could try?

    @Charlie_Hdz It's a Manjaro linux on x86_64. I would tend to agree with you, but I have no idea where to start looking.
    It's a ftdi.

  • Lifetime Qt Champion

    well i always use minicom as its so simple
    moserial is also cool. (X11)
    I dont know Manjaro so maybe there is another installed already

  • Hum, I'm not exactly sure how I can list all serial devices using minicom, but I have used libftdi and one of their example, and it lists my ftdi devices immediately.

  • Lifetime Qt Champion

    Oh, my bad, you actually type it so bad app for test.
    so libftdi can enum all ports and not hang?
    I wonder if it touches non ftdi ones. ( those not usb based)
    if time permits you can try
    (Søren Holm post)

    Anyway, its most likely something under /dev that makes it hang.

    I tried QSerialPortInfo on wm linux but i cant make it hang even when i remove
    the serial ports so they are missing.

  • @mrjj said in QSerialPortInfo::availablePorts() freeze for ~30s:

    I tried QSerialPortInfo on wm linux but i cant make it hang even when i remove
    the serial ports so they are missing.

    Sure, actually SerialPort tend to send "unknow" error messages instead of hanging functions.

  • Qt Champions 2020

    QSerialPortInfo does not use the open() system call if you do not call a deprecated isBusy() method (do not use it then). QSerialPortInfo use udev, sysfs and simple enumeration in /dev, in case previous methods were failed. You need to debug the QSerialPortInfo, or, at least try to strace a calls, where the stuck is happens.

    PS: It is interest to know in what of 'backend' this happens: with udev, sysfs or simple enumeration by a masks from /dev directory to localise an issue.

    PS2: From my expirience, the FTDI should work perfectly.

  • I'm pretty sure I use udev.
    However, it looks there was a bug somewhere that got fixed because after the latest system update from Manjaro, the issue has disappeared.
    No kernel or udev update though, so I am not sure what was at cause or what fixed it.

    Anyway, I guess this can be considered solved, thanks a lot for the support.

Log in to reply