Bug#903514: dringende Antwort
Ich habe wichtige Geschäfte mit Ihnen zu besprechen. Antwort für weitere Details. Wang Jianlin -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Bug#903514: Grüße mein Freund
Ich beabsichtige, Ihnen einen Teil meines Vermögens als freiwillige finanzielle Spende zukommen zu lassen. Wang Jianlin Wanda-Gruppe
Bug#903514: Deadlock in _dl_close join-ing threads accessing TLS (was Re: gimp won't launch)
Le 31/03/2019 à 22:53, Alexis Murzeau a écrit : > Le 31/03/2019 à 15:19, Aurelien Jarno a écrit : >> This bug is very likely a bug present in old glibc versions. It has been >> brought to light when enabling TLS support in openblas and not by a new >> glibc version. >> >> Right now the bug has been workarounded by disabling TLS support in >> openblas. The way to handle this bug is to write a small testcase that >> can be forwarded upstream. It's not an easy task though. >> > > Hi, > > I've made a test case here [0]. > I've not tested it against latest glibc commit. > But it does reproduce the deadlock with glibc 2.28 on Linux. > > To run the test case, do this: > ``` > gcc test_compiler_tls.c -o test_compiler_tls -ldl -g -pthread > gcc test_compiler_tls_lib.c -shared -o test_compiler_tls_lib.so \ > -g -pthread -fPIC > ./test_compiler_tls ./test_compiler_tls_lib & > gdb --pid $! -ex 'thr a a bt' > ``` > > This reproduce the deadlock that I've found in openblas: > 1- The test_thread open the library which call its constructor > 2- The library's constructor create a thread >`thread_that_use_tls_after_sleep` > 3- The thread `thread_that_use_tls_after_sleep` sleep for 100ms (this >needs to be enough so dl_close is called before the sleep ends) > 3- The test_thread close the library with dl_close > 4- dl_close lock `dl_load_lock` and call the library's destructor > 5- The library's destructor wait `thread_that_use_tls_after_sleep` to >finish > 6- The `thread_that_use_tls_after_sleep` thread try to read the TLS >variable which cause a call to `__tls_get_addr` > 7- `__tls_get_addr` cause a deadlock in `tls_get_addr_tail` trying to >lock the same `dl_load_lock` as dl_close does > 8- Nothing happen because dl_close thread is waiting for the >`thread_that_use_tls_after_sleep` thread to finish which having the >lock and the latter thread try to lock the same lock as dl_close and >so never exit. > > See [1] for the stacktrace. > > Thread 3 is the library's thread created in its constructor and joined > in its destructor. > Thread 2 is the thread that does dl_open and dl_close. > Thread 1 is a "monitoring" thread to implement a timeout of 10s (useful > if this tests need to run on a CI system) > > Where dl_close lock the `dl_load_lock`: [2] > Where tls_get_addr_tail lock the `dl_load_lock`: [3] > > [0]: https://gist.github.com/amurzeau/26f045bdfea407528dd7de3102fb4be7 > [1]: > https://gist.github.com/amurzeau/26f045bdfea407528dd7de3102fb4be7#file-gdb_stacktrace-txt > [2]: https://github.com/bminor/glibc/blob/glibc-2.28/elf/dl-close.c#L812 > [3]: https://github.com/bminor/glibc/blob/glibc-2.28/elf/dl-tls.c#L761 > Related links: https://bugzilla.redhat.com/show_bug.cgi?id=1409899 https://sourceware.org/bugzilla/show_bug.cgi?id=2377 Actually, the hang is caused by a C++ here, but that's the same deadlock (the C++ exception require the `dl_load_lock´ lock). It seems from the first link that using thread stuff in constructor and destructor is risky and not well supported and that applications should just avoid doing this. I didn't find a really related bug in sourceware bugzilla, maybe we should forward our bug to them ? -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#903514: Deadlock in _dl_close join-ing threads accessing TLS (was Re: gimp won't launch)
Le 31/03/2019 à 15:19, Aurelien Jarno a écrit : > This bug is very likely a bug present in old glibc versions. It has been > brought to light when enabling TLS support in openblas and not by a new > glibc version. > > Right now the bug has been workarounded by disabling TLS support in > openblas. The way to handle this bug is to write a small testcase that > can be forwarded upstream. It's not an easy task though. > Hi, I've made a test case here [0]. I've not tested it against latest glibc commit. But it does reproduce the deadlock with glibc 2.28 on Linux. To run the test case, do this: ``` gcc test_compiler_tls.c -o test_compiler_tls -ldl -g -pthread gcc test_compiler_tls_lib.c -shared -o test_compiler_tls_lib.so \ -g -pthread -fPIC ./test_compiler_tls ./test_compiler_tls_lib & gdb --pid $! -ex 'thr a a bt' ``` This reproduce the deadlock that I've found in openblas: 1- The test_thread open the library which call its constructor 2- The library's constructor create a thread `thread_that_use_tls_after_sleep` 3- The thread `thread_that_use_tls_after_sleep` sleep for 100ms (this needs to be enough so dl_close is called before the sleep ends) 3- The test_thread close the library with dl_close 4- dl_close lock `dl_load_lock` and call the library's destructor 5- The library's destructor wait `thread_that_use_tls_after_sleep` to finish 6- The `thread_that_use_tls_after_sleep` thread try to read the TLS variable which cause a call to `__tls_get_addr` 7- `__tls_get_addr` cause a deadlock in `tls_get_addr_tail` trying to lock the same `dl_load_lock` as dl_close does 8- Nothing happen because dl_close thread is waiting for the `thread_that_use_tls_after_sleep` thread to finish which having the lock and the latter thread try to lock the same lock as dl_close and so never exit. See [1] for the stacktrace. Thread 3 is the library's thread created in its constructor and joined in its destructor. Thread 2 is the thread that does dl_open and dl_close. Thread 1 is a "monitoring" thread to implement a timeout of 10s (useful if this tests need to run on a CI system) Where dl_close lock the `dl_load_lock`: [2] Where tls_get_addr_tail lock the `dl_load_lock`: [3] [0]: https://gist.github.com/amurzeau/26f045bdfea407528dd7de3102fb4be7 [1]: https://gist.github.com/amurzeau/26f045bdfea407528dd7de3102fb4be7#file-gdb_stacktrace-txt [2]: https://github.com/bminor/glibc/blob/glibc-2.28/elf/dl-close.c#L812 [3]: https://github.com/bminor/glibc/blob/glibc-2.28/elf/dl-tls.c#L761 -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#903514: Deadlock in _dl_close join-ing threads accessing TLS (was Re: gimp won't launch)
This bug is very likely a bug present in old glibc versions. It has been brought to light when enabling TLS support in openblas and not by a new glibc version. Right now the bug has been workarounded by disabling TLS support in openblas. The way to handle this bug is to write a small testcase that can be forwarded upstream. It's not an easy task though. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#903514: Deadlock in _dl_close join-ing threads accessing TLS (was Re: gimp won't launch)
Hi, On 07/09/2018 16:57, Sébastien Villemot wrote: > > I have just uploaded openblas 0.3.3+ds-1, which has TLS disabled. > > I think this should fix the original issue, i.e. the gimp+openblas > deadlock. Please let me know if this is not the case. > > Best, > Thanks for your update. I tried to start gimp with this openblas version installed and it did not crashed or hanged. But there's still a possible crash that can occur, when I do a test that does dl_open followed by dl_close of libopenblas, I get a segfault when stopping the thread that does the dl_open/dl_close. This crash doesn't seem to cause issues to gimp but might on some machines (maybe no threads are used by gimp when indirectly loading openblas and so the crash doesn't occur, but not sure at all). More extensive information here: [0]. If no one object that gimp doesn't crash anymore with that 3.3 version, maybe this bug can be closed (letting the crash of the dl_open/dl_close test be handled by upstream only [0]). [0] https://github.com/xianyi/OpenBLAS/issues/1720#issuecomment-418538099 -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#903514: Deadlock in _dl_close join-ing threads accessing TLS (was Re: gimp won't launch)
Le vendredi 10 août 2018 à 23:27 +0200, Alexis Murzeau a écrit : > On 09/08/2018 00:22, Alexis Murzeau wrote: > > On 08/08/2018 00:59, Alexis Murzeau wrote: > > > severity 903514 important > > > thanks > > > > > > > Reassigning to glibc with affects on openblas and gimp as this is caused > > > > by a deadlock inside glibc. > > I've posted a issue on openblas upstream project [0] and they suggested > > some solutions. > > One of them is to disable the use of compiler supported TLS and instead > > use pthreads. I have just uploaded openblas 0.3.3+ds-1, which has TLS disabled. I think this should fix the original issue, i.e. the gimp+openblas deadlock. Please let me know if this is not the case. Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#903514: libopenblas-base: version 0.3.2+ds-1 makes gimp hang indefinitely
Hi, On Tue, 14 Aug 2018 23:27:18 -0300 Rogério Brito wrote: > OK, now, to the actual report. With version 0.3.2 of openblas installed, > whenever I call gimp (I always start programs from the command line), it > just sits there and doesn't even show its splash screen. > > If I interrupt the execution with Ctrl+C, then I get a "Segmentation fault" > message, which would lead me to think that the program would not even have > finished being linked to all the shared libraries that it needs. > > If I run gimp under strace, I see that it hangs in a mutex call that never > proceeds. > I've suggested a patch to openblas here : [0] I've built a package with this patch available here: [1]. Instructions are on the same page [1]: execute: `apt-key adv --keyserver hkps://hkps.pool.sks-keyservers.net --recv-keys 0x3F7A2FA142E434FE06622560B05266B2EB68F001` and add `deb https://amurzeau.github.io/apt-repository unstable main` to sources.list. Then update openblas package to version `0.3.2+ds-1.1~1patchTLS`. Can you confirm if this patched package fixes your issue ? [0] https://salsa.debian.org/science-team/openblas/merge_requests/1 [1] https://amurzeau.github.io/apt-repository/ -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#903514: Deadlock in _dl_close join-ing threads accessing TLS (was Re: gimp won't launch)
On 12/08/2018 15:55, Jackie wrote: > Great. It works. > To make it clear, this is what I did to test: > > 1. Install libopenblas-base:amd64 (0.3.2+ds-1) and libopenblas-dev:amd64 > (0.3.2+ds-1) from official repo. After installation complete, open a > terminal and type gimp + ENTER. The cmd hangs forever and Ctrl-C gets a > segment fault. > 2. sudo apt purge libopenblas-base libopenblas-dev. Upon finish, open a > terminal and type gimp + ENTER. Gimp lanuches without problem. > 3. Add the repo you offered and install libopenblas-base:amd64 > (0.3.2+ds-1.1~1patchTLS) and libopenblas-dev:amd64 > (0.3.2+ds-1.1~1patchTLS). The installations go well, after that, open a > terminal and type gimp + ENTER. Gimp again lanuches without any problem. > > I think this validates both the existence of the bug and your solution. > Thank you very much. Thank you too for testing that patch :) Good to see it works for others having the gimp hang too. > > Jiang Jun -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#903514: Deadlock in _dl_close join-ing threads accessing TLS (was Re: gimp won't launch)
Great. It works. To make it clear, this is what I did to test: 1. Install libopenblas-base:amd64 (0.3.2+ds-1) and libopenblas-dev:amd64 (0.3.2+ds-1) from official repo. After installation complete, open a terminal and type gimp + ENTER. The cmd hangs forever and Ctrl-C gets a segment fault. 2. sudo apt purge libopenblas-base libopenblas-dev. Upon finish, open a terminal and type gimp + ENTER. Gimp lanuches without problem. 3. Add the repo you offered and install libopenblas-base:amd64 (0.3.2+ds-1.1~1patchTLS) and libopenblas-dev:amd64 (0.3.2+ds-1.1~1patchTLS). The installations go well, after that, open a terminal and type gimp + ENTER. Gimp again lanuches without any problem. I think this validates both the existence of the bug and your solution. Thank you very much. Jiang Jun On Sun, Aug 12, 2018 at 9:31 PM, Alexis Murzeau wrote: On 10/08/2018 23:27, Alexis Murzeau wrote: I can provide a binary package that include this patch, but I'm not sure this is the best thing to do (I'm not the official maintainer, nor know a good place to upload it). As I was requested to provide binary package to test the patch, I'm providing this as version `0.3.2+ds-1.1~1patchTLS` built with sbuild at [0]. Instructions are on the same page [0]: execute: `apt-key adv --keyserver hkps://hkps.pool.sks-keyservers.net --recv-keys 0x3F7A2FA142E434FE06622560B05266B2EB68F001` and add `deb https://amurzeau.github.io/apt-repository unstable main` to sources.list. This APT repository contains both the source and amd64 binary packages. If you try it, please tell if it works. [0] https://amurzeau.github.io/apt-repository/ -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F
Bug#903514: Deadlock in _dl_close join-ing threads accessing TLS (was Re: gimp won't launch)
On 10/08/2018 23:27, Alexis Murzeau wrote: > I can provide a binary package that include this patch, but I'm not sure > this is the best thing to do (I'm not the official maintainer, nor know > a good place to upload it). > As I was requested to provide binary package to test the patch, I'm providing this as version `0.3.2+ds-1.1~1patchTLS` built with sbuild at [0]. Instructions are on the same page [0]: execute: `apt-key adv --keyserver hkps://hkps.pool.sks-keyservers.net --recv-keys 0x3F7A2FA142E434FE06622560B05266B2EB68F001` and add `deb https://amurzeau.github.io/apt-repository unstable main` to sources.list. This APT repository contains both the source and amd64 binary packages. If you try it, please tell if it works. [0] https://amurzeau.github.io/apt-repository/ -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#903514: Deadlock in _dl_close join-ing threads accessing TLS (was Re: gimp won't launch)
Awesome, thanks! On Fri, Aug 10, 2018, 5:27 PM Alexis Murzeau wrote: > On 09/08/2018 00:22, Alexis Murzeau wrote: > > On 08/08/2018 00:59, Alexis Murzeau wrote: > >> severity 903514 important > >> thanks > >> > >>> Reassigning to glibc with affects on openblas and gimp as this is > caused > >>> by a deadlock inside glibc. > >> > >> Done. > >> > >> Lowering severity as this does not render any package unusable by > >> themselves, but only a combination of them (GIMP + OpenBLAS). > >> > >> I think a workaround solution against GIMP OpenBLAS should be done as > >> I'm not sure a good solution will emerge in glibc given attempts done in > >> the past. The work to be done seems non trivial. > >> > >> My though on possible solutions: > >> * Add a breaks between GIMP and OpenBLAS > >> * Disable TLS in OpenBLAS build (if possible, but this would cause a > >> performance loss for users that use OpenBLAS without gimp) > >> * Add a delay in GIMP to not load then close libraries too fast (so > >> OpenBLAS threads are fully initialized when dl_close is called on it) > >> > > > > Hi, > > > > I've posted a issue on openblas upstream project [0] and they suggested > > some solutions. > > One of them is to disable the use of compiler supported TLS and instead > > use pthreads. > > > > I tested this and it seems to fix deadlocks while starting gimp (I tried > > without arguments, with a non existing file and with an existing file). > > > > I've pushed a merge request with the patch at [1]. > > I've also asked openblas upstream if this patch could be a good solution. > > > > In that case would it be possible to have this patch tested for ones who > > have major instabilities with gimp + openblas ? > > > > Thanks :) > > > > Hi, > > I've updated the merge request [0] with the upstream proposed patch [1]. > > @openblas maintainers, maybe someone can build a package with this patch > and upload to experimental so others can check if gimp works fine with it ? > > I've myself tested it and gimp does not deadlock. > > I can provide a binary package that include this patch, but I'm not sure > this is the best thing to do (I'm not the official maintainer, nor know > a good place to upload it). > > [0] https://salsa.debian.org/science-team/openblas/merge_requests/1 > [1] https://github.com/xianyi/OpenBLAS/pull/1726 > > -- > Alexis Murzeau > PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F > >
Bug#903514: Deadlock in _dl_close join-ing threads accessing TLS (was Re: gimp won't launch)
On 09/08/2018 00:22, Alexis Murzeau wrote: > On 08/08/2018 00:59, Alexis Murzeau wrote: >> severity 903514 important >> thanks >> >>> Reassigning to glibc with affects on openblas and gimp as this is caused >>> by a deadlock inside glibc. >> >> Done. >> >> Lowering severity as this does not render any package unusable by >> themselves, but only a combination of them (GIMP + OpenBLAS). >> >> I think a workaround solution against GIMP OpenBLAS should be done as >> I'm not sure a good solution will emerge in glibc given attempts done in >> the past. The work to be done seems non trivial. >> >> My though on possible solutions: >> * Add a breaks between GIMP and OpenBLAS >> * Disable TLS in OpenBLAS build (if possible, but this would cause a >> performance loss for users that use OpenBLAS without gimp) >> * Add a delay in GIMP to not load then close libraries too fast (so >> OpenBLAS threads are fully initialized when dl_close is called on it) >> > > Hi, > > I've posted a issue on openblas upstream project [0] and they suggested > some solutions. > One of them is to disable the use of compiler supported TLS and instead > use pthreads. > > I tested this and it seems to fix deadlocks while starting gimp (I tried > without arguments, with a non existing file and with an existing file). > > I've pushed a merge request with the patch at [1]. > I've also asked openblas upstream if this patch could be a good solution. > > In that case would it be possible to have this patch tested for ones who > have major instabilities with gimp + openblas ? > > Thanks :) > Hi, I've updated the merge request [0] with the upstream proposed patch [1]. @openblas maintainers, maybe someone can build a package with this patch and upload to experimental so others can check if gimp works fine with it ? I've myself tested it and gimp does not deadlock. I can provide a binary package that include this patch, but I'm not sure this is the best thing to do (I'm not the official maintainer, nor know a good place to upload it). [0] https://salsa.debian.org/science-team/openblas/merge_requests/1 [1] https://github.com/xianyi/OpenBLAS/pull/1726 -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#903514: Deadlock in _dl_close join-ing threads accessing TLS (was Re: gimp won't launch)
On 08/08/2018 00:59, Alexis Murzeau wrote: > severity 903514 important > thanks > >> Reassigning to glibc with affects on openblas and gimp as this is caused >> by a deadlock inside glibc. > > Done. > > Lowering severity as this does not render any package unusable by > themselves, but only a combination of them (GIMP + OpenBLAS). > > I think a workaround solution against GIMP OpenBLAS should be done as > I'm not sure a good solution will emerge in glibc given attempts done in > the past. The work to be done seems non trivial. > > My though on possible solutions: > * Add a breaks between GIMP and OpenBLAS > * Disable TLS in OpenBLAS build (if possible, but this would cause a > performance loss for users that use OpenBLAS without gimp) > * Add a delay in GIMP to not load then close libraries too fast (so > OpenBLAS threads are fully initialized when dl_close is called on it) > Hi, I've posted a issue on openblas upstream project [0] and they suggested some solutions. One of them is to disable the use of compiler supported TLS and instead use pthreads. I tested this and it seems to fix deadlocks while starting gimp (I tried without arguments, with a non existing file and with an existing file). I've pushed a merge request with the patch at [1]. I've also asked openblas upstream if this patch could be a good solution. In that case would it be possible to have this patch tested for ones who have major instabilities with gimp + openblas ? Thanks :) -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#903514: Deadlock in _dl_close join-ing threads accessing TLS (was Re: gimp won't launch)
severity 903514 important thanks > Reassigning to glibc with affects on openblas and gimp as this is caused > by a deadlock inside glibc. Done. Lowering severity as this does not render any package unusable by themselves, but only a combination of them (GIMP + OpenBLAS). I think a workaround solution against GIMP OpenBLAS should be done as I'm not sure a good solution will emerge in glibc given attempts done in the past. The work to be done seems non trivial. My though on possible solutions: * Add a breaks between GIMP and OpenBLAS * Disable TLS in OpenBLAS build (if possible, but this would cause a performance loss for users that use OpenBLAS without gimp) * Add a delay in GIMP to not load then close libraries too fast (so OpenBLAS threads are fully initialized when dl_close is called on it) -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#903514: gimp won't launch
Hi, On Fri, 3 Aug 2018 22:53:08 -0400 James Van Zandt wrote: > Thanks, Benedict - the same solution worked for me. > > Specifically: > >sudo apt-get install libopenblas-base- libopenblas-dev- \ > libblas3 liblapack3 libblas-dev liblapack-dev > > Unfortunately julia and libjulia0.6 were also removed here, since they > depend on libopenblas-base. I intend to report this as a bug, and request > that they depend instead on the virtual packages libblas.so.3 and > liblapack.so.3 (which can also be provided by liblapack3 and libblas3, > resp.). After checking what could cause gimp issues, I found that on my machine, gimp almost always hang showing nothing (no splashscreen) when libopenblas-base is installed. Using gdb to find where it hung (gimp-gdb.txt) gives threads waiting on a lock while doing thread-local related stuff and the main thread is in the process of dl_close-ing openblas waiting the threads to exit using pthread_join. It seems that the lock used in `tls_get_addr_tail` [0] is the same as the one locked by _dl_close [1]. A recursive lock is used but here it does not help as the thread calling `tls_get_addr_tail` and `_dl_close` are not the same. This deadlock may not happen everytime, in my case, the openblas threads are still initializing while dl_close is called. Given this, I think the offending commit in openblas is bf40f806 [2] which add TLS variables to avoid locking. But many change were done since then. One of related bug report is [3] which seems to indicate that the locks handling is not easy inside glibc. There were an attempt to fix deadlocks between tls_get_addr and a dlclose of a module whose finalizer joins with that thread [4]. So I see these possibles solutions: * Add a breaks between gimp and openblas * Disable TLS in openblas build (if possible, but this would cause a performance loss for users that use openblas without gimp) * Patch glibc to not deadlock (but this seems not easy to do at all) Also, this deadlock might not be the only cause of issues encountered in this bug report. Reassigning to glibc with affects on openblas and gimp as this is caused by a deadlock inside glibc. [0] https://github.com/bminor/glibc/blob/glibc-2.27/elf/dl-tls.c#L761 [1] https://github.com/bminor/glibc/blob/glibc-2.27/elf/dl-close.c#L812 [2] https://github.com/xianyi/OpenBLAS/commit/bf40f806efa55c7a7c7ec57535919598eaeb569d#diff-31f8d4e8863583d95bf2f9529f83844e [4] https://sourceware.org/ml/libc-alpha/2015-06/msg00062.html -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F (gdb) thr a a bt Thread 4 (Thread 0x7f727a990700 (LWP 26238)): #0 0x7f7283ad711c in __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 #1 0x7f7283ad06c6 in __GI___pthread_mutex_lock (mutex=0x7f7287775968 <_rtld_global+2312>) at ../nptl/pthread_mutex_lock.c:113 #2 0x7f728775e5b7 in tls_get_addr_tail (ti=0x7f7278c2fc70, dtv=0x55edf85706b0, the_map=0x55edf8567980) at ../elf/dl-tls.c:761 #3 0x7f7287764288 in __tls_get_addr () at ../sysdeps/x86_64/tls_get_addr.S:55 #4 0x7f7276d86400 in get_memory_table () at memory.c:1147 #5 0x7f7276d86400 in blas_memory_alloc (procpos=procpos@entry=2) at memory.c:1147 #6 0x7f7276d86bbb in blas_thread_server (arg=0x2) at blas_server.c:297 #7 0x7f7283acdf2a in start_thread (arg=0x7f727a990700) at pthread_create.c:463 #8 0x7f7283a00edf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 3 (Thread 0x7f727b191700 (LWP 26237)): #0 0x7f7283ad711c in __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 #1 0x7f7283ad06c6 in __GI___pthread_mutex_lock (mutex=0x7f7287775968 <_rtld_global+2312>) at ../nptl/pthread_mutex_lock.c:113 #2 0x7f728775e5b7 in tls_get_addr_tail (ti=0x7f7278c2fc70, dtv=0x55edf85704b0, the_map=0x55edf8567980) at ../elf/dl-tls.c:761 #3 0x7f7287764288 in __tls_get_addr () at ../sysdeps/x86_64/tls_get_addr.S:55 #4 0x7f7276d86400 in get_memory_table () at memory.c:1147 #5 0x7f7276d86400 in blas_memory_alloc (procpos=procpos@entry=2) at memory.c:1147 #6 0x7f7276d86bbb in blas_thread_server (arg=0x1) at blas_server.c:297 #7 0x7f7283acdf2a in start_thread (arg=0x7f727b191700) at pthread_create.c:463 #8 0x7f7283a00edf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 2 (Thread 0x7f727b992700 (LWP 26236)): #0 0x7f7283ad711c in __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 #1 0x7f7283ad06c6 in __GI___pthread_mutex_lock (mutex=0x7f7287775968 <_rtld_global+2312>) at ../nptl/pthread_mutex_lock.c:113 #2 0x7f728775e5b7 in tls_get_addr_tail (ti=0x7f7278c2fc70, dtv=0x55edf8556c10, the_map=0x55edf8567980) at ../elf/dl-tls.c:761 #3 0x7f7287764288 in __tls_get_addr () at ../sysdeps/x86_64/tls_get_addr.S:55 #4 0x7f7276d86400 in get_memory_table () at memory.c:1147 #5 0x7f7276d86400 in
Bug#903514: gimp won't launch
Thanks, Benedict - the same solution worked for me. Specifically: sudo apt-get install libopenblas-base- libopenblas-dev- \ libblas3 liblapack3 libblas-dev liblapack-dev Unfortunately julia and libjulia0.6 were also removed here, since they depend on libopenblas-base. I intend to report this as a bug, and request that they depend instead on the virtual packages libblas.so.3 and liblapack.so.3 (which can also be provided by liblapack3 and libblas3, resp.).
Bug#903514: Gimp issues
Hi, Exact same results as Benedict Geihe, i.e., removing libopenblas-base solves the issue. Thanks A LOT for pointing this out Benedict! Best regards, -Pascal -- Homepage (http://giard.info) Debian GNU/Linux (http://www.debian.org) TCL: École polytechnique fédérale de Lausanne (http://tcl.epfl.ch)
Bug#903514: Related to openblas?
Hi all! I was following this report as I had exactly the same issue. Then i found this https://bbs.archlinux.org/viewtopic.php?id=238684 Indeed I had upgraded openblas recently and switching to the common blas, lapack solved the issue for me.
Bug#903514: GIMP won't launch
I note that, according to the strace log, gimp successfully read in 138 plugins, but failed on the very first plug-in that was a Python script. That can't be a coincidence. - Jim Van Zandt
Bug#903514: Gimp issues
Dear maintainer, In case that may shed some light... Before having gimp-python installed, gimp would start. I could modify images and save them in the native gimp format. Attempting to export to png or jpg would freeze though. (With the exportation processes visible with `ps` but not doing anything, it appears). After installing gimp-python, attempting to start gimp, I get stuck on the splash screen with status message "Interrogation des nouveaux greffons" (python-eval.py). Sorry, attempting to start with LC_ALL=C doesn't work; this loosely translates to "Querying new plugins". Killing gimp, either of the following process remains active /usr/bin/python2 /usr/lib/gimp/2.0/plug-ins/py-slice.py -gimp 12 11 -query 0 /usr/bin/python2 /usr/lib/gimp/2.0/plug-ins/python-eval.py -gimp 12 11 -query 0 Best regards, -Pascal -- Homepage (http://giard.info) Debian GNU/Linux (http://www.debian.org) TCL: École polytechnique fédérale de Lausanne (http://tcl.epfl.ch)
Bug#903514:
Package: gimp
Version: 2.10.2-1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
I may have the same problem. I updated many packages yesterday, and today
gimp will not launch.
Christoph reported that opening a .png file generated a splash screen
then error messages about babl and python. However, I get nothing (no
error message or splash screen) for any of these:
gimp
gimp foo.png# file does not exist
gimp g14601.png # file does exist
In each case, I got a segfault when I interrupted with ^C:
home:~$ gimp foo.png
^CSegmentation fault (core dumped)
I initially did not have gimp-python installed, but installing it didn't
help.
I then tried launching gimp with strace:
strace -o /tmp/log gimp
This time I got a splash screen (the first one I'd seen), with a progress
bar
stuck at 70%, the progress statement
Querying new Plug-ins
resynthesizer
plus these messages:
GEGL-Message: 12:45:41.515: Module
'/usr/lib/x86_64-linux-gnu/gegl-0.4/ff-load.so' load error:
/usr/lib/x86_64-linux-gnu/libhogweed.so.4: undefined symbol:
__gmpn_cnd_sub_n
GEGL-Message: 12:45:41.534: Module
'/usr/lib/x86_64-linux-gnu/gegl-0.4/ff-save.so' load error:
/usr/lib/x86_64-linux-gnu/libhogweed.so.4: undefined symbol:
__gmpn_cnd_sub_n
Missing fast-path babl conversion detected, Implementing missing babl
fast paths
accelerates GEGL, GIMP and other software using babl, warnings are
printed on
first occurance of formats used where a conversion has to be synthesized
programmatically by babl based on format description
*WARNING* missing babl fast path(s): "R'G'B' double" to "CIE Lab double"
The strace file showed that the last file opened was
/usr/lib/gimp/2.0/plug-ins/plugin-uncrop.py:
home:~$ grep -n "open" /tmp/log |tail -22
39878:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/cml-explorer",
O_RDONLY) = 14
39961:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/checkerboard",
O_RDONLY) = 14
40059:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/cartoon", O_RDONLY) =
14
40147:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/border-average",
O_RDONLY) = 14
40250:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/blur", O_RDONLY) = 14
40317:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/blinds", O_RDONLY) = 14
40413:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/animation-play",
O_RDONLY) = 14
40505:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/animation-optimize",
O_RDONLY) = 14
40712:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/align-layers",
O_RDONLY) = 14
40799:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/webexport", O_RDONLY)
= 14
40912:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/gap_wr_trans",
O_RDONLY) = 14
41229:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/gap_wr_resynth",
O_RDONLY) = 14
41337:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/gap_wr_opacity",
O_RDONLY) = 14
41441:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/gap_wr_color_levels",
O_RDONLY) = 14
41613:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/gap_wr_color_huesat",
O_RDONLY) = 14
41765:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/wavelet-denoise",
O_RDONLY) = 14
41874:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/streak", O_RDONLY) = 14
41955:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/separate_import",
O_RDONLY) = 14
42063:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/separate", O_RDONLY) =
14
42610:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/resynthesizer_gui",
O_RDONLY) = 14
42759:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/resynthesizer",
O_RDONLY) = 14
42875:openat(AT_FDCWD, "/usr/lib/gimp/2.0/plug-ins/plugin-uncrop.py",
O_RDONLY) = 14
The next time gimp froze again after opening the same file, but the
progress statement in the splash screen was:
Querying new Plug-ins
plugin-uncrop.py
(The last line is from memory. The splash screen got covered by other
windows, and was not re-rendered when uncovered.)
The second strace output ended like this:
home:~$ tail -50 /tmp/log2
poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}], 2, 0) = 0 (Timeout)
recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily
unavailable)
recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily
unavailable)
recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily
unavailable)
recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily
unavailable)
recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily
unavailable)
recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily
unavailable)
recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily
unavailable)
recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily
unavailable)
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3,
revents=POLLOUT}])
writev(3,
[{iov_base="5\30\4\0,\2\300\3\3\0\300\3\0\5e\0\213\4\6\0-\2\300\3,\2\300\3\204\1\0\0"...,
iov_len=1688}, {iov_base=NULL, iov_len=0},
Bug#903514: gimp doesn’t start up and segfaults when interrupted
Package: gimp Version: 2.10.2-1 Followup-For: Bug #903514 Dear Maintainer, I have the same problem. Last week gimp was functioning normally, now it doesn’t even start up and segfaults when interrupted by Ctrl+C. My python installation is fully functional, I use python every day. Regards, Harald -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.16.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages gimp depends on: ii gimp-data2.10.2-1 ii libaa1 1.4p5-44+b2 ii libbabl-0.1-01:0.1.52-dmo1 ii libbz2-1.0 1.0.6-8.1 ii libc62.27-4 ii libcairo21.15.10-3 ii libfontconfig1 2.13.0-5 ii libfreetype6 2.8.1-2 ii libgcc1 1:8.1.0-9 ii libgdk-pixbuf2.0-0 2.36.11-2 ii libgegl-0.4-01:0.4.4-dmo1 ii libgexiv2-2 0.10.8-1 ii libgimp2.0 2.10.2-1 ii libglib2.0-0 2.56.1-2 ii libgs9 9.22~dfsg-2.1 ii libgtk2.0-0 2.24.32-2 ii libgudev-1.0-0 232-2 ii libharfbuzz0b1.8.2-2 ii libheif1 1.3.2-1 ii libilmbase23 2.2.1-2 ii libjpeg62-turbo 1:1.5.2-2+b1 ii liblcms2-2 2.9-2 ii liblzma5 5.2.2-1.3 ii libmng1 1.0.10+dfsg-3.1+b5 ii libmypaint-1.3-0 1:1.3.0-dmo6 ii libopenexr23 2.2.1-4 ii libopenjp2-7 2.3.0-1 ii libpango-1.0-0 1.42.1-2 ii libpangocairo-1.0-0 1.42.1-2 ii libpangoft2-1.0-01.42.1-2 ii libpng16-16 1.6.34-2 ii libpoppler-glib8 0.63.0-2 ii librsvg2-2 2.40.20-2 ii libstdc++6 8.1.0-9 ii libtiff5 4.0.9-6 ii libwebp6 0.6.1-2 ii libwebpdemux20.6.1-2 ii libwebpmux3 0.6.1-2 ii libwmf0.2-7 0.2.8.4-12 ii libx11-6 2:1.6.5-1 ii libxcursor1 1:1.1.15-1 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxmu6 2:1.1.2-2 ii libxpm4 1:3.5.12-1 ii xdg-utils1.1.3-1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages gimp recommends: ii ghostscript 9.22~dfsg-2.1 Versions of packages gimp suggests: pn gimp-data-extras pn gimp-help-en | gimp-help ii gimp-python 2.10.2-1 pn gvfs-backends ii libasound21.1.6-1 -- no debconf information
Bug#903514: gimp: completely broken
On Tue, 2018-07-10 at 17:20 -0400, Jeremy Bicha wrote: > I don't know. It works fine here. Could you try to be more specific > about *when* things stopped working? I'm afraid I have no idea... I noticed it a week ago, which doesn't mean though, that it wasn't introduced earlier. Wasn't there recently some change in the python packaging, when Python 2 was split out into python2* packages (which the normal "python*" packages depend upon however)? > Does it help if you install gimp-python? Hmm, at least not at a first glance... When starting plain: $ gimp or when opening some $ gimp foo.png it hangs at it's GUI splash screen at "python-eval.py". After Ctrl+C there's a 24556 pts/6Sl 0:00 /usr/bin/python2 /usr/lib/gimp/2.0/plug-ins/python-eval.py -gimp 14 13 -query 0 left. > Do you have anything unusual with your python install? Nothing that I'd know of (I'm actually not using Python myself, so it's only plain package installations as required for dependencies) > Does python > otherwise work? It seems so... or at least s many other things in a normal desktop Debian use python... nothing of that shows any issues recently. Thanks!
Bug#903514: gimp: completely broken
On Tue, Jul 10, 2018 at 4:59 PM, Christoph Anton Mitterer wrote: > Since some time the GIMP is completely broken. I don't know. It works fine here. Could you try to be more specific about *when* things stopped working? > GIMP-Error: Unable to run plug-in "plugin-uncrop.py" > (/usr/lib/gimp/2.0/plug-ins/plugin-uncrop.py) > > Failed to execute child process “python” (No such file or directory) Does it help if you install gimp-python? Do you have anything unusual with your python install? Does python otherwise work? Thanks, Jeremy Bicha
Bug#903514: gimp: completely broken
Package: gimp Version: 2.10.2-1 Severity: grave Justification: renders package unusable Hi. Since some time the GIMP is completely broken. In most cases it does not even start (e.g. when invoking it from another program) or when: $ gimp or $ gimp 0.jpg (with 0.jpg not existing) it simply hangs (with no GUI coming up) when doing e.g.: $ gimp Screenshot\ from\ 2018-06-02\ 04-36-57.png Missing fast-path babl conversion detected, Implementing missing babl fast paths accelerates GEGL, GIMP and other software using babl, warnings are printed on first occurance of formats used where a conversion has to be synthesized programmatically by babl based on format description *WARNING* missing babl fast path(s): "R'G'B' double" to "CIE Lab double" GIMP-Error: Unable to run plug-in "plugin-uncrop.py" (/usr/lib/gimp/2.0/plug-ins/plugin-uncrop.py) Failed to execute child process “python” (No such file or directory) GIMP-Error: Unable to run plug-in "plugin-resynth-sharpen.py" (/usr/lib/gimp/2.0/plug-ins/plugin-resynth-sharpen.py) Failed to execute child process “python” (No such file or directory) GIMP-Error: Unable to run plug-in "plugin-resynth-fill-pattern.py" (/usr/lib/gimp/2.0/plug-ins/plugin-resynth-fill-pattern.py) Failed to execute child process “python” (No such file or directory) GIMP-Error: Unable to run plug-in "plugin-resynth-enlarge.py" (/usr/lib/gimp/2.0/plug-ins/plugin-resynth-enlarge.py) Failed to execute child process “python” (No such file or directory) gimp: LibGimpBase-WARNING: gimp: gimp_wire_read(): error GIMP-Error: Unable to run plug-in "plugin-map-style.py" (/usr/lib/gimp/2.0/plug-ins/plugin-map-style.py) Failed to execute child process “python” (No such file or directory) GIMP-Error: Unable to run plug-in "plugin-heal-transparency.py" (/usr/lib/gimp/2.0/plug-ins/plugin-heal-transparency.py) Failed to execute child process “python” (No such file or directory) GIMP-Error: Unable to run plug-in "plugin-heal-selection.py" (/usr/lib/gimp/2.0/plug-ins/plugin-heal-selection.py) Failed to execute child process “python” (No such file or directory) One get's these weird python errors... Even when Ctrl+C or killall gimp and so on, processes like: 10423 ?Sl 0:00 /usr/lib/gimp/2.0/plug-ins/file-jpeg -gimp 35 33 -run 0 10443 ?Sl 0:00 /usr/lib/gimp/2.0/plug-ins/file-jpeg -gimp 39 37 -run 0 10556 ?Sl 0:00 /usr/lib/gimp/2.0/plug-ins/file-jpeg -gimp 47 45 -run 0 10571 ?Sl 0:00 /usr/lib/gimp/2.0/plug-ins/file-jpeg -gimp 51 49 -run 0 are left behind Trying to open or save files from within gimp, often leads to the GUI simply hanging. And even tools like the Free Select Tool are broken... on can start a selection but not connect the two endpoints. All this happens even with .config/GIMP and friends completel removed. Cheers, Chris. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.17.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8), LANGUAGE=en_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gimp depends on: ii gimp-data2.10.2-1 ii libaa1 1.4p5-44+b2 ii libbabl-0.1-00.1.50-1 ii libbz2-1.0 1.0.6-8.1 ii libc62.27-4 ii libcairo21.15.10-3 ii libfontconfig1 2.13.0-5 ii libfreetype6 2.8.1-2 ii libgcc1 1:8.1.0-9 ii libgdk-pixbuf2.0-0 2.36.11-2 ii libgegl-0.4-00.4.2-1 ii libgexiv2-2 0.10.8-1 ii libgimp2.0 2.10.2-1 ii libglib2.0-0 2.56.1-2 ii libgs9 9.22~dfsg-2.1 ii libgtk2.0-0 2.24.32-2 ii libgudev-1.0-0 232-2 ii libharfbuzz0b1.8.2-2 ii libheif1 1.3.2-1 ii libilmbase23 2.2.1-2 ii libjpeg62-turbo 1:1.5.2-2+b1 ii liblcms2-2 2.9-2 ii liblzma5 5.2.2-1.3 ii libmng1 1.0.10+dfsg-3.1+b5 ii libmypaint-1.3-0 1.3.0-2 ii libopenexr23 2.2.1-4 ii libopenjp2-7 2.3.0-1 ii libpango-1.0-0 1.42.1-2 ii libpangocairo-1.0-0 1.42.1-2 ii libpangoft2-1.0-01.42.1-2 ii libpng16-16 1.6.34-2 ii libpoppler-glib8 0.63.0-2 ii librsvg2-2 2.40.20-2 ii libstdc++6 8.1.0-9 ii libtiff5 4.0.9-6 ii libwebp6 0.6.1-2 ii libwebpdemux20.6.1-2 ii libwebpmux3 0.6.1-2 ii libwmf0.2-7 0.2.8.4-12 ii libx11-6 2:1.6.5-1 ii libxcursor1 1:1.1.15-1 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxmu6 2:1.1.2-2 ii libxpm4 1:3.5.12-1 ii xdg-utils1.1.3-1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages gimp recommends: ii ghostscript 9.22~dfsg-2.1 Versions
