Capabilities option causes segfault if no monitors detected

[rockowitz]

@gadefox reported on issue #29

The app without root permissions shows empty display list*. In this case Capabilities option in menu causes a segmentation fault. That's the reason I can't use the latest version, cause you automatically try to show display capabilities (therefore I get a segmentation fault immediately after start).

I believe you need to check this condition in the code..

Open failed for /dev/i2c-1: errno=EACCES(13): Permission denied Open failed for /dev/i2c-2: errno=EACCES(13): Permission denied Open failed for /dev/i2c-3: errno=EACCES(13): Permission denied Open failed for /dev/i2c-4: errno=EACCES(13): Permission denied Open failed for /dev/i2c-5: errno=EACCES(13): Permission denied

[rockowitz]

The latest changes on the 0.2.0-dev branch disable view selection if no monitors are detected. I believe this addresses the segfault you reported and additional cases such as selecting the Features view if there are no monitors.

Please let me know whether there is still a problem.

However, I am puzzled by the statement "you automatically try to show display capabilities (therefore I get a segmentation fault immediately after start)". Display of capabilities is not automatic - it requires selecting the Capabilities view. If the failure occurs without having to select the Capabilities view, please send the console log for this case.

As an aside, your post suggests that ddcui must be run as root. This is not the case.The logged on user simply requires RW permissions to the /dev/i2c devices. Typically this is granted by assigning /dev/i2c devices to group i2c, setting group RW permissions on the /dev/i2c devices , and assigning the logged on user to group i2c. For details, see the ddcutil documentation.

[gadefox]

To be honest, I don't know exactly - it's just my guess.. And you're right, no monitors are listed in the combo box without RW permissions plus I see 4 warnings in the terminal. I believe this is correct behaviour, but the app crashes when I choose one of 3 options in the first menu. And unfortunately the latest version crashes immediately at the beginning. I think it would be nice to check this condition.

[rockowitz]

When you write "the app crashes when I choose one of 3 options in the first menu", I believe you're describing the behaviour without the latest changes.

As to "the latest version crashes immediately at the beginning. I think it would be nice to check this condition.", I need more information to diagnose the problem. I'm not clairvoyant . At the very least, submit the console output as an attachment. Even better, if you know how, run ddcui under valgrind, and submit the console output. If that is not possible, execute "ddcui --trace api". The latter will at least give some idea of where the crash is happening. I gather from your other posts that you are running an i386 version of Debian 11 (Bullseye).

[audunmg]

I'm also experiencing segfault immediately.

I'm running arch, and using ddcui built from AUR using latest commit 448ee8a

This happens on my laptop, with the first monitor being the buildt in eDP panel without ddc support, the second monitor on HDMI with ddc support, it works fine when i use ddcutil.

Valgrind run:

==821164== Memcheck, a memory error detector
==821164== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==821164== Using Valgrind-3.17.0 and LibVEX; rerun with -h for copyright info
==821164== Command: ddcui
==821164== 
==821164== Invalid read of size 8
==821164==    at 0x152244: parse_ddcui_command (in /usr/bin/ddcui)
==821164==    by 0x13EC57: main (in /usr/bin/ddcui)
==821164==  Address 0x8 is not stack'd, malloc'd or (recently) free'd
==821164== 
==821164== 
==821164== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==821164==  Access not within mapped region at address 0x8
==821164==    at 0x152244: parse_ddcui_command (in /usr/bin/ddcui)
==821164==    by 0x13EC57: main (in /usr/bin/ddcui)
==821164==  If you believe this happened as a result of a stack
==821164==  overflow in your program's main thread (unlikely but
==821164==  possible), you can try to increase the size of the
==821164==  main thread stack using the --main-stacksize= flag.
==821164==  The main thread stack size used in this run was 8388608.
==821164== 
==821164== HEAP SUMMARY:
==821164==     in use at exit: 1,952,337 bytes in 15,081 blocks
==821164==   total heap usage: 63,361 allocs, 48,280 frees, 80,158,607 bytes allocated
==821164== 
==821164== LEAK SUMMARY:
==821164==    definitely lost: 32 bytes in 1 blocks
==821164==    indirectly lost: 192 bytes in 6 blocks
==821164==      possibly lost: 3,808 bytes in 12 blocks
==821164==    still reachable: 1,948,289 bytes in 15,061 blocks
==821164==                       of which reachable via heuristic:
==821164==                         newarray           : 192 bytes in 6 blocks
==821164==         suppressed: 16 bytes in 1 blocks
==821164== Rerun with --leak-check=full to see details of leaked memory
==821164== 
==821164== For lists of detected and suppressed errors, rerun with: -s
==821164== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)

Without valgrind, it only produces

Segmentation fault (core dumped)

Would you like the core dump?

[rockowitz]

@audunmg What happens if you build from the current official ddcui tarball? If it fails, valgrind should pinpoint the exact source file location of the segfault.