motis generate tool gets stuck with wrong configurated date

[1Maxnet1]

When I execute the motis generate tool with a generate-config.ini as following:

query_count=1
message_type=routing
start_type=pretrip
dest_type=station
routers=/nigiri
dataset.begin=20230212
import.paths=schedule-bw:/data/motis-bw/gtfs

the tool gets stuck and doesn't finish, even if its only one query to generate.
The GTFS dataset is newer and therefore does not provide trips for such an old date. Additionally the config.ini to run the server is also set to TODAY, instead of the outdated date.

Not a big deal (for me), as I figured out what the problem was, but for your information and in case someone else has a similar problem, this issue can be the reference on how to fix it. Additionally it would be nice to have a error message, explaining the issue, instead of just getting stuck.

[vkrause]

Might be entirely unrelated but I also managed to produce an infinite loop (log output shows a continuous stream of operations between /lookup/geo_station and /ppr/route, ie. not a deadlock), on the Swiss national dataset when enabling car parking as one of the start modes. A single query between arbitrary coordinates is enough it seems, the only way to recover is killing the server then.

So hardening against that seems like a good idea indeed, although that might very well be easier said than done.

[felixguendling]

I guess those two problems are unrelated. The /lookup/geo_station <-> /ppr/route loop seems more critical as this can make denial of service attacks very easy (and cannot be prevented with a simple rate limiting proxy).

The motis generate problem is something I also hit, but it's easy to detect (query generation should take only a few seconds).

If someone feels like fixing it, those loops would require a breaking condition of maybe 10000 iterations until something like std::terminate is called after printing some helpful message.

motis/modules/intermodal/src/eval/generator/intermodal_generator.cc

Lines 359 to 368 in fa978f6

	do {
	// http://mathworld.wolfram.com/DiskPointPicking.html
	double const radius =
	std::sqrt(real_dist_(mt_)) * (max_dist / scale_factor(ref_merc));
	double const angle =
	real_dist_(mt_) * 2 * boost::math::constants::pi<double>();
	auto const pt_merc = geo::merc_xy{ref_merc.x_ + radius * std::cos(angle),
	ref_merc.y_ + radius * std::sin(angle)};
	pt = geo::merc_to_latlng(pt_merc);
	} while (bounds_ != nullptr && !bounds_->contains(pt));

motis/modules/intermodal/src/eval/generator/intermodal_generator.cc

Lines 726 to 735 in fa978f6

	do {
	from = sched
	.stations_[random_station_id(station_nodes, motis_interval_start,
	motis_interval_end)]
	.get();
	to = sched
	.stations_[random_station_id(station_nodes, motis_interval_start,
	motis_interval_end)]
	.get();
	} while (from == to);

motis/modules/intermodal/src/eval/generator/intermodal_generator.cc

Lines 702 to 704 in fa978f6

	do {
	s = *rand_in(first, last);
	} while (!has_events(*s, motis_interval_start, motis_interval_end));

I would prioritize fixing the infinite loop that can occur in production way higher than the developer support tooling.

[vkrause]

Thanks for the pointers, I'll see if I can break my loop with those.

[felixguendling]

Oops, I should not have mixed the issues. These loops are all in the motis generate command. For the loop you describe, I would need to have a debugger somewhere in motis_call to see who triggers those requests (and why):

motis/base/module/include/motis/module/context/motis_call.h

Lines 12 to 25 in 8b6cbec

	inline future motis_call_impl(msg_ptr const& msg, ctx::op_id id) {
	if (dispatcher::direct_mode_dispatcher_ != nullptr) {
	ctx_data d{dispatcher::direct_mode_dispatcher_};
	return dispatcher::direct_mode_dispatcher_->req(msg, d, id);
	} else {
	auto const op = ctx::current_op<ctx_data>();
	auto& data = op->data_;
	id.parent_index = op->id_.index;
	return data.dispatcher_->req(msg, data, id);
	}
	}
	#define motis_call(msg) \
	motis::module::motis_call_impl(msg, ctx::op_id(CTX_LOCATION))