Project-OSRM/node-osrm

Segmentation fault on Ubuntu 16.04

perliedman opened this issue · 4 comments

Hi,

I'm trying to use node-osrm on Ubuntu 16.04 with a very small dataset for some basic tests. However, I'm having no luck, since it appears any call to node-osrm causes a segmentation fault.

I'm running node-osrm 5.4.3, and have tried with the pre-built binaries as well as with building against a OSRM instance I built locally (it works without problems as long as I don't try it from node).

This is running Node 4.6.2 on x86_64.

I realize this might still be a bit vague to track down the problem, what steps can I take to give you more information?

Hrm, here is what I would try:

  • build osrm-backend master (!) locally
  • build node-osrm master (!) locally against your libosrm

this will give you what will become more or less the 5.5 release in a couple of days.

If this setup still segfaults try getting more information out of it: we publish debug binaries (npm install osrm --debug). Try running these under gdb to get a backtrace (bt) after the segfault happened.

If this does not help then try if you can reproduce it in a clean Ubuntu 16.04 Docker container. This makes sure your setup is not broken (think: compiler, stdlib, lua and related issues). We can take it from there.

cc @danpat we need to figure out if this is an issue with 5.5 and if so fix it before doing the release.

Thanks for the quick and detailed response, of course I found the real issue on my side almost immediately after posting this.

It's still a bit weird, but probably a low priority issue if any. Anyway, accidentally I had put a process.exit that was done before OSRM had responded, which apparently gives a segmentation fault, likely since the process is being in some state of termination when the callback is actually called.

The code looked like this:

        osrm.match({
                coordinates: feature.geometry.coordinates,
                timestamps: feature.properties.coordTimes
            }, function(err, response) {
                if (err) {
                    console.log(err);
                    process.exit(1);
                }
                console.log(response.tracepoints); // array of Waypoint objects
                console.log(response.matchings); // array of Route objects
            });

            process.exit(0);

Notice that process.exit(0) will be called directly after the match call.

Moving the exit call into the callback fixes the issue.

Sorry for alerting you because of a trivial problem on my part!

Great!

I don't think there is an elegant and easy way for us to handle users shutting down the process hard. What we already do is hold onto the osrm object in the NodeJs bindings until the last callback finished:

// Ref-counted OSRM alive even after shutdown until last callback is done
std::shared_ptr<osrm::OSRM> this_;