Bug 492220 - Plasma Coredump after installation of openjph/libopenjph
Summary: Plasma Coredump after installation of openjph/libopenjph
Status: RESOLVED DOWNSTREAM
Alias: None
Product: plasmashell
Classification: Plasma
Component: Startup process (show other bugs)
Version: 6.1.4
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-08-26 15:08 UTC by Gerald Cox
Modified: 2024-08-27 22:48 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
plasmashell kcrash (15.75 KB, text/vnd.kde.kcrash-report)
2024-08-26 15:08 UTC, Gerald Cox
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gerald Cox 2024-08-26 15:08:27 UTC
Created attachment 172976 [details]
plasmashell kcrash

SUMMARY
After openjph installation SDDM has black screen.  I then switch to GDM and then Plasma fails with coredump (attached). 
Appears to work fine in GNOME.

[KCrash Handler]
#4  0x00007f4e640bd295 in _sub_I_65535_0.0 () at /lib64/libopenjph.so.0.15
#5  0x00007f4ea9d76437 in call_init (l=<optimized out>, argc=2, argv=0x7ffddc116e38, env=0x5561b168f430) at dl-init.c:74
#6  call_init (l=<optimized out>, argc=2, argv=0x7ffddc116e38, env=0x5561b168f430) at dl-init.c:26
#7  0x00007f4ea9d7652d in _dl_init (main_map=0x7f4e240380d0, argc=2, argv=0x7ffddc116e38, env=0x5561b168f430) at dl-init.c:121
#8  0x00007f4ea9d725c2 in __GI__dl_catch_exception (exception=exception@entry=0x0, operate=operate@entry=0x7f4ea9d7d560 <call_dl_init>, args=args@entry=0x7f4e655feed0) at dl-catch.c:211
#9  0x00007f4ea9d7d4fc in dl_open_worker (a=a@entry=0x7f4e655ff080) at dl-open.c:829
#10 0x00007f4ea9d72523 in __GI__dl_catch_exception (exception=exception@entry=0x7f4e655ff060, operate=operate@entry=0x7f4ea9d7d460 <dl_open_worker>, args=args@entry=0x7f4e655ff080) at dl-catch.c:237
#11 0x00007f4ea9d7d904 in _dl_open (file=0x7f4e2400e400 "/usr/lib64/libheif/libheif-jphenc.so", mode=<optimized out>, caller_dlopen=0x7f4e721c17bd <PluginLibrary_Unix::load_from_file(char const*)+29>, nsid=<optimized out>, argc=2, argv=0x7ffddc116e38, env=0x5561b168f430) at dl-open.c:905

STEPS TO REPRODUCE
Install openjph

OBSERVED RESULT
Plasma crash

EXPECTED RESULT
Normal operation




Operating System: Fedora Linux 40
KDE Plasma Version: 6.1.4
KDE Frameworks Version: 6.5.0
Qt Version: 6.7.2
Kernel Version: 6.10.6-200.fc40.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 8 × AMD FX(tm)-8350 Eight-Core Processor
Memory: 31.2 GiB of RAM
Graphics Processor: AMD Radeon HD 7800 Series
 

ADDITIONAL INFORMATION
Upstream bug for openjph here: https://github.com/aous72/OpenJPH/issues/152
Fedora bugzilla here: https://bugzilla.redhat.com/show_bug.cgi?id=2307795
Comment 1 Antonio Rojas 2024-08-26 15:57:59 UTC
It's an illegal instruction, so a packaging issue in the openjph package (compiled with march=native)
Comment 2 Aous Naman 2024-08-26 21:17:55 UTC
(In reply to Antonio Rojas from comment #1)
> It's an illegal instruction, so a packaging issue in the openjph package
> (compiled with march=native)

Hi Antonio,

Do you know what the illegal instruction is that is causing the problem?
Also, what is the CPU the code is running on?
Pointers on how to identify the problem from my side.

OpenJPH has multiple code paths, supporting different SIMD instructions.  
It looks like the problem is happening during the loading of the library, so it it the library initializing code. Am I correct?

Thank you.
Aous.
Comment 3 Aous Naman 2024-08-27 22:48:13 UTC
(In reply to Aous Naman from comment #2)
> 
> (In reply to Antonio Rojas from comment #1)
> > It's an illegal instruction, so a packaging issue in the openjph package
> > (compiled with march=native)
> 
> Hi Antonio,
> 
> Do you know what the illegal instruction is that is causing the problem?
> Also, what is the CPU the code is running on?
> Pointers on how to identify the problem from my side.
> 
> OpenJPH has multiple code paths, supporting different SIMD instructions.  
> It looks like the problem is happening during the loading of the library, so
> it it the library initializing code. Am I correct?
> 
> Thank you.
> Aous.

Gerald Cox closed the case.  Thank you.