Closed #756.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/756#event-4211399979___
Rpm-maint mailing list
Based on internal testing, the above seems to have cured the remaining cases,
so considering closed.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Yup, at least one such issue has just been addressed here:
https://github.com/file/file/commit/81f15c2b
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I dug a bit deeper: the issue happens when libmagic calls out to external
executables, which isn't implemented in a thread-safe way, and locks up.
Enabling internal compression support (done via linking to libraries) makes the
issue go away.
--
You are receiving this because you are
Let's work together and sort the problem. If you would like me to run
additional diagnostics, I'd be happy to help.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Anyway, there *will* be a bugfix release to 4.15.x soonish, there's a handful
of fairly critical things that needs addressing. I mean, it is a .0 release...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
TBH, the thought of reverting the whole damn threading business has crossed my
mind more than once by now, it is (quite expectedly) proving painful. I've
resisted the temptation so far...
The thing is that this hasn't been an issue on Fedora *at all*, AFAIK. If we
just disable without
TBH, this seems like a serious enough issue in 4.15.0 release, that parallel
file classification should be simply disabled for the time being, with a
4.15.0.1 issued to include that.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
Sadly, I am seeing this when rpm is linked against file 5.37 as well. Here's a
couple tracebacks obtained by attaching gdb to running (hanging) rpm processes:
0x7fc5a9ee22a1 in ?? () from /usr/lib/x86_64-linux-gnu/libgomp.so.1
(gdb) bt
#0 0x7fc5a9ee22a1 in ?? () from
For the record, there have been some reports of builds hanging during
classification on systems with large number of CPUs using file 5.36 which where
fixed by updating to 5.37. Another workaround is to set %_smp_build_nthreads to
a smaller number, ultimately 1 to make the whole classification
When using MAGIC_COMPRESS (as rpmfc does), libmagic may fork helper executables
to deal with decompressing files. Since commit
41f0e214f2266f02d6185ba11f797716de8125d4 we are running the classifier in
threads, and mixing fork() and threads tends to mean trouble.
Filing this ticket as a
11 matches
Mail list logo
