Crash on Fedora 30 #476
Comments
|
I noticed the same problem after my upgrade to Fedora 30. I decided to compile the current revision myself (was e956825). It did crash just the same. After deleting this controller section and the next section (same square bracket regex) the program still crashed on startup but in a different place but also calling std::regex. When replacing all calls of std::regex in the program with boost::regex as was the case before commit c732f9b the the program works flawlessly on Fedora 30. I am compiling with gcc version 9.1.1 20190503 (Red Hat 9.1.1-1). I do not know enough about the differences in the regex implementations betweet STL and boost so I would not call the step back to boost a fix for this problem, just some insight. |
|
Issue still persists in Fedora 31. Tested version is 1.2-0.3.20190419git4ed8ec7.fc31 |
|
With what version of performous did you test? (what commit hash) |
|
Yes, I also would think that the commit hash is 4ed8ec7. But there should be some insight in my previous comment on Jul 6, 2019:
|
|
Hmmm as far as i know and may be able to test. Building a sample program with gcc9.1.0 and gcc9.2.0 with c++11 support so we have to dig deeper i think.. @skmqpbusfz can you try out above code and see if it both returns '1' ? |
|
Just compiled your suggested code snippet with g++ (gcc version 9.2.1 20190827 (Red Hat 9.2.1-1) (GCC)). |
|
Alright so std regex'es do work but Performous is doing something weird with them resulting in a error. Could you paste a debug log of performous? |
|
I just tried it with the version of the Fedora RPM Fusion Repo, the flag
I also wanted to try with the current master version but it does not compile on my system as of now. Looks like the same issue as #490 |
|
Hmmm maybe related to the change in fedora 28 changing I've added a list of strings in the repo where we use
Quickfix might be to use Longterm fix would be to support this flag and fix our code |
|
I looked at the comments of @SimonPe in issue #490 and with his cleanup of the cmake scripts I can now compile the current master. So I added the
After compiling the program still crashes with the same error as usual:
Also to note, the RPM Fusion repo version worked in Fedora 29. The hardening flags should have been present there, shouldn't they? |
|
Ummh, why does the assertion fail in the first place? Shouldn't the Performous code be fixed rather than the check disabled? Presumably controllers.cc:113 should be relevant here, so why does std::regex_search fail with these arguments? if (!regex_search(devName, deviceRegex)) return false;Or is the actual error somewhere else? |
|
Having the same problem on fedora 30, here is the full backtrace in gdb: |
|
looks like a fedora problem see: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4QLUFDXCED3IDLHS5PCIXILKXFIUMPBU/ (where is exactly failing the assertion in performous) |
|
0001-Workaround-failing-regex-on-FC30.patch.txt wrote some kind of workaround so that it does not crash on fedora 30... |
|
It looks like an ok patch to me, save you should use angled brackets to include Anyway, you should open a PR |
This is mainly a workaround for bug performous#476
This is mainly a workaround for bug #476
|
With #496 merged into master can we close this issue?@jorritjorritsma |
|
Closing this issue for now. If it's not working please reopen this ticket :) |
|
for the record, the boost issue is boostorg/locale#52 |
Do you want to request a feature or report a bug?
Bug
What did you do?
I started the application
What did you expect to see?
the performous application
What did you see instead?
Performous crashed immediately with the following output
Output of
performous --version: (What version of Performous are you using?)What is your environment & configuration (arguments, platform, ...)?
OS: Fedora 30 x86_64
System: HP EliteBook 840 G3
As Performous didn't work to my expectations on Ubuntu 19.04 I tried Fedora, hence this was a newly installed system with rpmfusion enabled.
The text was updated successfully, but these errors were encountered: