Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#1287 closed defect/bug (fixed)

navit 0.5.0-6021 java.lang.InternalError

Reported by: kazer Owned by: KaZeR
Priority: major Milestone:
Component: core Version: git master
Severity: normal Keywords:


User reported crash from Google Play store

java.lang.InternalError: Thread starting during runtime shutdown
at java.lang.Thread.nativeCreate(Native Method)
at java.lang.Thread.start(
at org.apache.http.impl.conn.tsccm.AbstractConnPool.enableConnectionGC(
at org.apache.http.impl.conn.tsccm.ThreadSafeClientConnManager.createConnectionPool(
at org.apache.http.impl.conn.tsccm.ThreadSafeClientConnManager.<init>(
at org.acra.util.HttpRequest.getHttpClient(
at org.acra.util.HttpRequest.sendPost(
at org.acra.sender.GoogleFormSender.send(
at org.acra.SendWorker.sendCrashReport(
at org.acra.SendWorker.checkAndSendReports(

We have 13 reports of this issue on Android 5.0

User comments: "Die App stürzt sofort ab beim Versuch, einen Kartendownload vorzubereiten. Google Nexus 4." "жопа не вачайте" "can't download maps" "failed when trying to download maps"

Change History (4)

comment:1 Changed 7 years ago by tryagain

I was able to reproduce it in emulator with android 5.0.1.

I had to disable acra to be able to get actual backtrace. Somehow it doesnt work on lollipop for us.

It looks like Lollipop attempts to unload (garbage-collect?) our primary activity when we switch to map download activity.

So we have static member Navit.NavitResources? reinitialized to null.


matching_maps.put("category_name", Navit.NavitResources.getString(R.string.maps_for_current_location));


matching_maps.put("category_name", getResources().getString(R.string.maps_for_current_location));

Works around the problem. Also, we could leave above line as is, but remove static from NavitResources? definition.

Another surprise, is that country names are not localized for me. They should go through _() member function of Navit and finally be translated by NavitGraphics?.getLocalizedString which calls jni. But they are not.

At the same time, internal gui strings are translated inside jni.

Looks like there is some incompatibility ntroduced in lollipop.

I do not commit any changes right now because i do not fully understand why this happens.

comment:2 Changed 7 years ago by tryagain

Navit seems to bring lollipop ART VM (that's the ancestor of Dalvik VM) to some inconsistent state.

I was unable to reproduce this bug even with Android 4.4.2 switched to ART mode.

But in lollipop Navit is unable to catch NullPointerException? with the following code ( Navit_text_lookup is not null, get(in) returns null):

			out = Navit_text_lookup.get(in).get(main_language);
		catch (Exception e)
			// most likely there is not translation yet
			Log.e("NavitTextTranslations", "lookup: exception");
			out = null;

Navit process just dies, saying in log that it's exited normally.

If we do manual comparison, everything goes ok:

		if(Navit_text_lookup!=null && Navit_text_lookup.get(in)!=null)

I feel there's something really bad with vm. There are a few similar reports, like this one

I guess our problem could be:

  • our native code (that's core navit codebase) doing something bad with memory;
  • our native code not conforming to jni specification (may be, calling jni functions with an exception pending, or can something else ruin the vm?);
  • some third party jar we use (TTS_lib~ub.jar, acra-4.~b2.jar) has some jni which does something of above;
  • more options?

After Navit process exits, it's immediately gets restarted by thesystem, but now Navit activity is not started, so no native navit code initialization occurs (including gettext initialization). Only NavitDownloadSelectMapActivity? activity is started which now works fine. But we have no translations because native gettext was not initialized properly.

Any ideas?

Last edited 7 years ago by tryagain (previous) (diff)

comment:3 Changed 7 years ago by tryagain

  • Resolution set to fixed
  • Status changed from new to closed

Lollipop VM appears to use SIGSEGV handling to fire up NullPointerException?'s. I had to disable catching that signal on android. Anyway, we did not do anything usable on Android in that signal handler.

Problem should be fixed with r6033.

comment:4 Changed 7 years ago by kazer

Great work tryagain! That was fast!

Note: See TracTickets for help on using tickets.