<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Crash in: libc-2.27.so after setting Named Ranges to e.g. F:F (non-absolute columns)" href="https://bugs.documentfoundation.org/show_bug.cgi?id=122643#c9">Comment # 9</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Crash in: libc-2.27.so after setting Named Ranges to e.g. F:F (non-absolute columns)" href="https://bugs.documentfoundation.org/show_bug.cgi?id=122643">bug 122643</a> from <a class="email" href="mailto:michael.meeks@collabora.com" title="Michael Meeks <michael.meeks@collabora.com>"> Michael Meeks</a> <pre>Thanks Julien; as you say - all false positives from glibc internals assuming knowledge of their own allocator (which is fine). The DispatchUserEvents thing really looks like memory corruption though: warn:vcl:11210:11210:vcl/source/app/salusereventlist.cxx:120: Uncaught St12out_of_range multi_type_vector::position#1570: block position not found! (logical pos=1048580, block size=4, logical size=1048576) I would assume that in fact under valgrind we don't get a crash either ;-) which is annoying - presumably it perterbs threading so the issue doesn't happen. What might help is getting another valgrind trace when run with: --fair-sched=yes It is also possible that we need to substantially reduce this eg: coregrind/m_scheduler/scheduler.c:#define SCHEDULING_QUANTUM 1200 // 100000 To get a better approximation of fast context switching to catch the race. It is somewhat odd that this isn't a cmd-line option for valgrind particularly since there is no performance benefit of it not being configurable; possibly an easy-hack for valgrind lurks there =)</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>