<div dir="ltr"><div><div><div><div><div><div>Hello Frederik,<br><br></div>thank you for reporting and bisecting the first bad commit. <br></div>I
 was able to reproduce the issue with foot profile for Europe and at the
 first glance the problem is in access to an stxxl vector name_data 
and/or name_offsets in CmpEdgeByInternalSourceTargetA<wbr>ndName call std::lexicographical_compare.<br>I would suggest to create an issue at <a href="https://github.com/Project-OSRM/osrm-backend/issues" target="_blank">https://github.com/Project-<wbr>OSRM/osrm-backend/issues</a> to keep a track of it.<br></div><br></div>From my side i will try to bisect name id  during the week that leads to memory corruption.<br><br></div>Kind regards,<br></div>Michael<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 10, 2016 at 10:46 AM, Frederik Ramm <span dir="ltr"><<a href="mailto:frederik@remote.org" target="_blank">frederik@remote.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<span class=""><br>
On 10/07/2016 09:43 AM, Frederik Ramm wrote:<br>
> I have finished bisecting the commits and ended up with<br>
> 2b466b2fb29c416149b4d881c15134<wbr>9218a63e1e as the first bad commit -<br>
> everything before that works, everything after that segfaults. I'll have<br>
> a closer look.<br>
<br>
</span>I'm afraid I couldn't pinpoint the problem. I'm pretty sure there is<br>
*some* kind of memory corruption but exactly when and where it hits<br>
seems to be dependent on the STXXL configuration among other things.<br>
<br>
To summarize:<br>
<br>
* The problem is always reported as "double free or corruption<br>
(fasttop)" and leads to a segfault in osrm-extract on Ubuntu 16.04.<br>
<br>
* The problem affects all OSRM versions from commit<br>
2b466b2fb29c416149b4d881c15134<wbr>9218a63e1e on (this means v5.2.7 is the<br>
last-known-good release). I read through that commit and couldn't<br>
immediately see anything that looks broken.<br>
<br>
* The problem does not occur with the "car" profile but it does occur<br>
with the "bicycle" and "foot" profiles.<br>
<br>
* The problem does not occur with data extracts smaller than ~ 2 GB but<br>
it does occur with larger ones. Sadly that made it impossible for me to<br>
find a very small input file that would provoke the crash, and any<br>
"valgrind" debugging was out of the question.<br>
<br>
I'll leave it at that and work with 5.2.7 which is good enough for my<br>
use case. Given that you say all profiles work for you in 5.4, it might<br>
be a funny edge case on Ubuntu or even on this particular machine I was<br>
running it on. Time permitting I might re-run on a different machine<br>
some time later.<br>
<div class="HOEnZb"><div class="h5"><br>
Bye<br>
Frederik<br>
<br>
--<br>
Frederik Ramm  ##  eMail <a href="mailto:frederik@remote.org">frederik@remote.org</a>  ##  N49°00'09" E008°23'33"<br>
<br>
______________________________<wbr>_________________<br>
OSRM-talk mailing list<br>
<a href="mailto:OSRM-talk@openstreetmap.org">OSRM-talk@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/osrm-talk" rel="noreferrer" target="_blank">https://lists.openstreetmap.<wbr>org/listinfo/osrm-talk</a><br>
</div></div></blockquote></div><br></div>