Closed bernt-matthias closed 3 years ago
Thanks for reporting and my apologies for the inconvenience. It seems that the issue is only triggered when fasta is used as input, hence it escaped detection for a long time. It has now been fixed in nanomath v1.2.1 (pushed to PyPI, probably soon updated on bioconda).
Cheers, Wouter
Thanks. Just bumped the recipe https://github.com/bioconda/bioconda-recipes/pull/28433
May I just ask another question here. I'm working on the Galaxy tool wrapper for NanoPlot. I have the problem that the png images are not generated in the containerized tests. I guess there is some library missing in the requirements of the NanoPlot recipe. Any idea what this could be?
Can you access the log file? Does the process have Internet access while running? Kaleido is used for the png images, and similar problems have been reported...
The log file says:
2021-05-11 15:16:57,812 No static plots are saved due to some kaleido problem:
2021-05-11 15:16:57,812 Failed to start Kaleido subprocess. Error stream:
[0511/151657.584631:WARNING:resource_bundle.cc(431)] locale_file_path.empty() for locale
[0511/151657.602031:WARNING:resource_bundle.cc(431)] locale_file_path.empty() for locale
[0511/151657.603772:WARNING:resource_bundle.cc(431)] locale_file_path.empty() for locale
[0511/151657.604856:WARNING:discardable_shared_memory_manager.cc(194)] Less than 64MB of free space in temporary directory for shared memory files: 0
[0511/151657.625941:ERROR:platform_shared_memory_region_posix.cc(250)] Creating shared memory in .org.chromium.Chromium.DGgLi9 failed: Permission denied (13)
[0511/151657.626020:ERROR:platform_shared_memory_region_posix.cc(253)] Unable to access(W_OK|X_OK) .: Permission denied (13)
Received signal 6
#0 0x55c8fbc3ed79 base::debug::CollectStackTrace()
#1 0x55c8fbbbc633 base::debug::StackTrace::StackTrace()
#2 0x55c8fbc3e95b base::debug::(anonymous namespace)::StackDumpSignalHandler()
#3 0x7f4379a9c730 (/lib/x86_64-linux-gnu/libpthread-2.28.so+0x1272f)
#4 0x7f437958a7bb gsignal
#5 0x7f4379575535 abort
#6 0x55c8fbbea30a base::internal::OnNoMemoryInternal()
#7 0x55c8fbbea329 base::(anonymous namespace)::OnNoMemory()
#8 0x55c8fbbea319 base::TerminateBecauseOutOfMemory()
#9 0x55c8fbbd40ab base::FieldTrialList::InstantiateFieldTrialAllocatorIfNeeded()
#10 0x55c8fbbd4239 base::FieldTrialList::CopyFieldTrialStateToFlags()
#11 0x55c8fa72ff82 content::GpuProcessHost::LaunchGpuProcess()
#12 0x55c8fa72e910 content::GpuProcessHost::Init()
#13 0x55c8fa72e6c2 content::GpuProcessHost::Get()
#14 0x55c8fab4bb6e base::internal::Invoker<>::RunOnce()
#15 0x55c8fbc02306 base::TaskAnnotator::RunTask()
#16 0x55c8fbc13cf6 base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWorkImpl()
#17 0x55c8fbc139ea base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWork()
#18 0x55c8fbc60899 base::MessagePumpLibevent::Run()
#19 0x55c8fbc1459b base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run()
#20 0x55c8fbbed9bd base::RunLoop::Run()
#21 0x55c8fa5d5f18 content::BrowserProcessSubThread::IOThreadRun()
#22 0x55c8fbc2c874 base::Thread::ThreadMain()
#23 0x55c8fbc4ecaa base::(anonymous namespace)::ThreadFunc()
#24 0x7f4379a91fa3 start_thread
#25 0x7f437964c4cf clone
r8: 0000000000000000 r9: 00007f437738cf50 r10: 0000000000000008 r11: 0000000000000246
r12: 000055c8f8620780 r13: 000055c8f8562eb0 r14: 00001839a42f6cc0 r15: 00001839a4327240
di: 0000000000000002 si: 00007f437738cf50 bp: 00007f437738d1b0 bx: 0000000000000006
dx: 0000000000000000 ax: 0000000000000000 cx: 00007f437958a7bb sp: 00007f437738cf50
ip: 00007f437958a7bb efl: 0000000000000246 cgf: 002b000000000033 erf: 0000000000000000
trp: 0000000000000000 msk: 0000000000000000 cr2: 0000000000000000
[end of stack trace]
Calling _exit(1). Core file will not be generated.
So indeed a kaleido problem, unfortunately. These errors are intercepted to make sure they don't crash NanoPlot itself.
Could solve it by exporting the TMPDIR
variable.
Glad to hear that! Thanks for the feedback.
For the following call
NanoPlot --tsv_stats --fasta read_0.fasta read_1.fasta -o '.'
I get:The call does not crash without
--tsv_stats