IOException with Mapsforge 0.51

[Martin Vennekamp]

Hi, 

I'm using your libary in my small APP ;-) Did work like charm,great work!

I use the map within a fragment. Now, after updating from 0.5 to 0.51 I get an empty map whenever I rotate the map + the following error in LOGCAT:

 null

 java.io.IOException: lseek failed: EBADF (Bad file number)

  at java.io.RandomAccessFile.seek(RandomAccessFile.java:606)

  at org.mapsforge.map.reader.IndexCache.getIndexEntry(IndexCache.java:95)

  at org.mapsforge.map.reader.MapFile.processBlocks(MapFile.java:512)

  at org.mapsforge.map.reader.MapFile.readMapData(MapFile.java:341)

  at org.mapsforge.map.layer.renderer.DatabaseRenderer.executeJob(DatabaseRenderer.java:183)

  at org.mapsforge.map.layer.renderer.MapWorker.renderTile(MapWorker.java:88)

  at org.mapsforge.map.layer.renderer.MapWorker.doWork(MapWorker.java:65)

  at org.mapsforge.map.util.PausableThread.run(PausableThread.java:140)

 Caused by: libcore.io.ErrnoException: lseek failed: EBADF (Bad file number)

  at libcore.io.Posix.lseek(Native Method)

  at libcore.io.ForwardingOs.lseek(ForwardingOs.java:88)

  at java.io.RandomAccessFile.seek(RandomAccessFile.java:604)

  ... 7 more

Any quick ideas what I done wrong?

Thanks in Advance  & Regards,

Martin

[Emux]

From first glance something seems wrong with the map file reading.

AFAIK Android restarts an activity at device map orientation changes.
You can keep this behavior or just disable it by adding the following at activity in manifest:
android:configChanges="keyboardHidden|orientation|screenSize"

Also are you sure you're following the Mapsforge life cycle properly?
You can check it's simple implementation at Getting-Started-Android-App wiki.

--
Emux
Cruiser - Atlas

[Emux]

Also take care that you have actually a valid map file.

[Martin Vennekamp]

Hi,

that did not solve the Problem, and I think I have to look deeper into the Problem. When I have a Little bit more time I will come back with a more elaborated example. ;-)

I'll retain the Fragment using the fragmentmanager:

private static final String MapTAG = ItemDetailFragment.class.getSimpleName();

[...]

(...inside the onCreate Method of FragmentActivity...)

Fragment fMap = getFragmentManager().findFragmentByTag(MapTAG);

if ( fMap == null) fMap = new ItemDetailFragment();

FragmentTransaction ft = getSupportFragmentManager().beginTransaction();
ft.replace(R.id.item_detail_container, fMap, MapTAG);
ft.commit();

While, in your example (ItemDetailActivity.java) the Fragment is re-created on each call of 'onCreate'.

Regards,

Martin

[Martin Vennekamp]

Ok, I think I got it...

I stored the map file (i.e. MapFile-Object) in a static field. and returned it using a getMapFile()-method. However, this worked for previous version. but with 0.5.1 it did'nt. 

Re-Creating the Mapfile instead of storing it solved the problem.

Regards,

Martin

P.S.: Sorry for beeing some kind of cryptic...

[Emux]

In 0.5.1 there is the introduction of MapDataStore, so we have indeed changes to MapFile object.

[M. Dietrich]

hi,

Am Sonntag, 12. April 2015 22:54:36 UTC+2 schrieb Martin Vennekamp:

 java.io.IOException: lseek failed: EBADF (Bad file number)

  at java.io.RandomAccessFile.seek(RandomAccessFile.java:606)

  at org.mapsforge.map.reader.IndexCache.getIndexEntry(IndexCache.java:95)

  at org.mapsforge.map.reader.MapFile.processBlocks(MapFile.java:512)

  at org.mapsforge.map.reader.MapFile.readMapData(MapFile.java:341)

  at org.mapsforge.map.layer.renderer.DatabaseRenderer.executeJob(DatabaseRenderer.java:183)

  at org.mapsforge.map.layer.renderer.MapWorker.renderTile(MapWorker.java:88)

  at org.mapsforge.map.layer.renderer.MapWorker.doWork(MapWorker.java:65)

  at org.mapsforge.map.util.PausableThread.run(PausableThread.java:140)

 Caused by: libcore.io.ErrnoException: lseek failed: EBADF (Bad file number)

  at libcore.io.Posix.lseek(Native Method)

  at libcore.io.ForwardingOs.lseek(ForwardingOs.java:88)

  at java.io.RandomAccessFile.seek(RandomAccessFile.java:604)

  ... 7 more

i have that exact error with 1.5.2rc2 and 1.5.2 still. i use plain MultiMapDataStore, but have many, many map files. the error occures occationally, after restart the same area is rendered fine. its not related on how long the app is running. with 1.5.2rc2 i even had reboots but have no real evidence that this is related.

regards, m.

[Emux]

(I cleared the topic of the multiple same posts)

On 11/11/2015 04:03 μμ, M. Dietrich wrote:

i use plain MultiMapDataStore, but have many, many map files. the error occures occationally, after restart the same area is rendered fine. its not related on how long the app is running.

Multi-threading rendering is off right ?

And how many map files are open?

--
Emux

[Ludwig]

I think this can actually happen when you restart the activity (like after purging the cache) because the thread that reads the map file is still active when the map file is closed. 

Could you check if this could be the cause? Also: does your app crash because of this? 

On 11 November 2015 at 22:03, M. Dietrich <emd...@gmail.com> wrote:

hi,

Am Sonntag, 12. April 2015 22:54:36 UTC+2 schrieb Martin Vennekamp:

 java.io.IOException: lseek failed: EBADF (Bad file number)

  at java.io.RandomAccessFile.seek(RandomAccessFile.java:606)

  at org.mapsforge.map.reader.IndexCache.getIndexEntry(IndexCache.java:95)

  at org.mapsforge.map.reader.MapFile.processBlocks(MapFile.java:512)

  at org.mapsforge.map.reader.MapFile.readMapData(MapFile.java:341)

  at org.mapsforge.map.layer.renderer.DatabaseRenderer.executeJob(DatabaseRenderer.java:183)

  at org.mapsforge.map.layer.renderer.MapWorker.renderTile(MapWorker.java:88)

  at org.mapsforge.map.layer.renderer.MapWorker.doWork(MapWorker.java:65)

  at org.mapsforge.map.util.PausableThread.run(PausableThread.java:140)

 Caused by: libcore.io.ErrnoException: lseek failed: EBADF (Bad file number)

  at libcore.io.Posix.lseek(Native Method)

  at libcore.io.ForwardingOs.lseek(ForwardingOs.java:88)

  at java.io.RandomAccessFile.seek(RandomAccessFile.java:604)

  ... 7 more

i have that exact error with 1.5.2rc2 and 1.5.2 still. i use plain MultiMapDataStore, but have many, many map files. the error occures occationally, after restart the same area is rendered fine. its not related on how long the app is running. with 1.5.2rc2 i even had reboots but have no real evidence that this is related.

regards, m.

--
You received this message because you are subscribed to the Google Groups "mapsforge-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapsforge-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/7915091c-9cf2-4fda-8507-8a6593611c6c%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Emux]

On 11/11/2015 04:23 μμ, Ludwig wrote:

I think this can actually happen when you restart the activity (like after purging the cache) because the thread that reads the map file is still active when the map file is closed.

Activity restart could also happen on device orientation change (enabled by default).

--
Emux

[M. Dietrich]

Am Mittwoch, 11. November 2015 15:23:49 UTC+1 schrieb Ludwig:

I think this can actually happen when you restart the activity (like after purging the cache) because the thread that reads the map file is still active when the map file is closed. 

it happens after minutes of watching the app without even touching (or moving/turning ;) ) the device

 

Could you check if this could be the cause? Also: does your app crash because of this? 

the app is terminated when that happens.

btw: it is a bit different from the above in the beginning:

11-10 15:59:31.201 E/MapFile (19658): lseek failed: EBADF (Bad file number)

11-10 15:59:31.201 E/MapFile (19658): java.io.IOException: lseek failed: EBADF (Bad file number)

11-10 15:59:31.201 E/MapFile (19658):   at java.io.RandomAccessFile.seek(RandomAccessFile.java:602)

11-10 15:59:31.201 E/MapFile (19658):   at org.mapsforge.map.reader.IndexCache.getIndexEntry(IndexCache.java:95)

11-10 15:59:31.201 E/MapFile (19658):   at org.mapsforge.map.reader.MapFile.processBlocks(MapFile.java:487)

11-10 15:59:31.201 E/MapFile (19658):   at org.mapsforge.map.reader.MapFile.readMapData(MapFile.java:326)

11-10 15:59:31.201 E/MapFile (19658):   at org.mapsforge.map.reader.MultiMapDataStore.readMapData(MultiMapDataStore.java:184)

11-10 15:59:31.201 E/MapFile (19658):   at org.mapsforge.map.reader.MultiMapDataStore.readMapData(MultiMapDataStore.java:138)

11-10 15:59:31.201 E/MapFile (19658):   at org.mapsforge.map.layer.renderer.DatabaseRenderer.executeJob(DatabaseRenderer.java:138)

11-10 15:59:31.201 E/MapFile (19658):   at org.mapsforge.map.layer.renderer.MapWorkerPool$MapWorker.run(MapWorkerPool.java:119)

11-10 15:59:31.201 E/MapFile (19658):   at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)

11-10 15:59:31.201 E/MapFile (19658):   at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)

11-10 15:59:31.201 E/MapFile (19658):   at java.lang.Thread.run(Thread.java:818)

11-10 15:59:31.201 E/MapFile (19658): Caused by: android.system.ErrnoException: lseek failed: EBADF (Bad file number)

11-10 15:59:31.201 E/MapFile (19658):   at libcore.io.Posix.lseek(Native Method)

11-10 15:59:31.201 E/MapFile (19658):   at libcore.io.BlockGuardOs.lseek(BlockGuardOs.java:163)

11-10 15:59:31.201 E/MapFile (19658):   at java.io.RandomAccessFile.seek(RandomAccessFile.java:600)

11-10 15:59:31.201 E/MapFile (19658):   ... 10 more

the logger is probably from mapsforges, so the have been catched i assume but wasnt?

[M. Dietrich]

Am Mittwoch, 11. November 2015 15:53:50 UTC+1 schrieb M. Dietrich:

the logger is probably from mapsforges, so the have been catched i assume but wasnt?

... , so i assume it could have been catched but wasnt?

some more information: i have self created map files and installed many, many of those for testing (around 170). i doubt that the creation is to blame because corrupted files would trigger a different behaviour, right?

maybe mapsforge closes the file accidentially but still using it?

[Emux]

Is it on Android or Java?

And are the maps on a storage that e.g. when the device is usb connected to pc, the storage is not temporarily available internally?

--
Emux

[Ludwig]

There is a closeFile method in MapFile. Can I suggest that you put some logging into that method that also includes printing the stack trace, so we can see who initiates the close?

As to why this can happen when you even leave the app untouched: Android will perform some sort of cleanup once in a while, e.g. when the device goes to sleep or to recover resources to use for other apps. 

My feeling is that we have a problem with the shutdown order here: the rendering thread is still active when the mapfile is closed. 

There is might not be a much cleaner way to do this, but maybe what we should do is:

• set a flag that the map file is being closed intentionally.
• catch the IOException and kill the reading thread when the flag is set

Ludwig

--

You received this message because you are subscribed to the Google Groups "mapsforge-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapsforge-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/56437D70.4070007%40gmail.com.

[Ludwig]

I am actually a bit surprised that the app terminates, in the readMapData() method there is already a catch clause that catches IOExceptions. (Quick check it seems to be there in 0.5.1 as well).

Ludwig

[Emux]

I can reproduce the issue mentioned above with Samples app.

If we go at the Settings and start checking (or unchecking) fast the layers at the bottom,
eventually the exception appears at the log.

--
Emux

[M. Dietrich]

...but the app does not terminate? 

[Emux]

On 16/11/2015 05:39 μμ, M. Dietrich wrote:

...but the app does not terminate?

No, all continue to work normally.

The exception is thrown inside a try/catch, so it's strange to crash the app.

--
Emux

[Emux]

BTW in latest code the calls start from here.

Can you try with latest 0.6 RC version?

--
Emux

[M. Dietrich]

the bug still exists (sorry for taking so long, work was demanding ;) )

Am Montag, 16. November 2015 18:32:33 UTC+1 schrieb Emux:

BTW in latest code the calls start from here.

i assume some code is closing the file which is later still used - is that the scenario? shouldnt the close() be monitored closely?

Can you try with latest 0.6 RC version?

 

11-23 15:44:53.185 E/MapFile (23087): lseek failed: EBADF (Bad file number)

11-23 15:44:53.185 E/MapFile (23087): java.io.IOException: lseek failed: EBADF (Bad file number)

11-23 15:44:53.185 E/MapFile (23087):  at java.io.RandomAccessFile.seek(RandomAccessFile.java:602)

11-23 15:44:53.185 E/MapFile (23087):  at org.mapsforge.map.reader.IndexCache.getIndexEntry(IndexCache.java:95)

11-23 15:44:53.185 E/MapFile (23087):  at org.mapsforge.map.reader.MapFile.processBlocks(MapFile.java:460)

11-23 15:44:53.185 E/MapFile (23087):  at org.mapsforge.map.reader.MapFile.readMapData(MapFile.java:805)

11-23 15:44:53.185 E/MapFile (23087):  at org.mapsforge.map.datastore.MultiMapDataStore.readMapData(MultiMapDataStore.java:149)

11-23 15:44:53.185 E/MapFile (23087):  at org.mapsforge.map.datastore.MultiMapDataStore.readMapData(MultiMapDataStore.java:137)

11-23 15:44:53.185 E/MapFile (23087):  at org.mapsforge.map.layer.renderer.DatabaseRenderer.executeJob(DatabaseRenderer.java:138)

11-23 15:44:53.185 E/MapFile (23087):  at org.mapsforge.map.layer.renderer.MapWorkerPool$MapWorker.run(MapWorkerPool.java:121)

11-23 15:44:53.185 E/MapFile (23087):  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)

11-23 15:44:53.185 E/MapFile (23087):  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)

11-23 15:44:53.185 E/MapFile (23087):  at java.lang.Thread.run(Thread.java:818)

11-23 15:44:53.185 E/MapFile (23087): Caused by: android.system.ErrnoException: lseek failed: EBADF (Bad file number)

11-23 15:44:53.185 E/MapFile (23087):  at libcore.io.Posix.lseek(Native Method)

11-23 15:44:53.185 E/MapFile (23087):  at libcore.io.BlockGuardOs.lseek(BlockGuardOs.java:163)

11-23 15:44:53.185 E/MapFile (23087):  at java.io.RandomAccessFile.seek(RandomAccessFile.java:600)

11-23 15:44:53.185 E/MapFile (23087):  ... 10 more

[M. Dietrich]

btw: i always see 4 of those stacktraces before the app terminates.

[Ludwig]

The reading and the closing of the file happens on different threads, the exception happens if the closing thread (on the main UI line) runs first, while the reading thread still reads. Thread cancellation is notoriously difficult, but we catch the exception and I do not see why the app should terminate at that point. The exception is caught and ignored.

Usually when you app crashes with some exception you will also see something like an 'unhandled exception' message. This does not seem to be the case here. 

Do you run with multiple threads for reading map data? That would explain why you get the message four times. Otherwise I do not think that the reading thread gets rescheduled after the file is closed. 

Can you post the full error messages belonging to your apps process id? I think there must be something missing that will give a better hint what is crashing your app. (find out your process id (e.g. 23087) and grep the log on this).

Ludwig

On 24 November 2015 at 00:23, M. Dietrich <emd...@gmail.com> wrote:

btw: i always see 4 of those stacktraces before the app terminates.

--

You received this message because you are subscribed to the Google Groups "mapsforge-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapsforge-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/06443722-3bba-4235-872c-12aafeb4af75%40googlegroups.com.

[M. Dietrich]

Am Dienstag, 24. November 2015 01:13:36 UTC+1 schrieb Ludwig:

The reading and the closing of the file happens on different threads, the exception happens if the closing thread (on the main UI line) runs first, while the reading thread still reads. Thread cancellation is notoriously difficult, but we catch the exception and I do not see why the app should terminate at that point. The exception is caught and ignored.

may it be an exception during exception processing? especially in difficult states like OOM? 

Usually when you app crashes with some exception you will also see something like an 'unhandled exception' message. This does not seem to be the case here. 

my app catches own exception by  Thread.setDefaultUncaughtExceptionHandler(...) - it just logges the exception in there and finishes (see my sample at https://github.com/emdete/ItsDown/blob/master/mapsforge/01.getting_started/src/main/java/org/pyneo/android/gui/Sample.java#L41), may that be the cause?

Do you run with multiple threads for reading map data? That would explain why you get the message four times. Otherwise I do not think that the reading thread gets rescheduled after the file is closed. 

i use the mapsforge default as far as i know - is it enabled in the 0.6 rc?

Can you post the full error messages belonging to your apps process id? I think there must be something missing that will give a better hint what is crashing your app. (find out your process id (e.g. 23087) and grep the log on this).

 will do - could not (re)produce it right now.

[Emux]

On 24/11/2015 07:36 μμ, M. Dietrich wrote:

Am Dienstag, 24. November 2015 01:13:36 UTC+1 schrieb Ludwig:

The exception is caught and ignored.

may it be an exception during exception processing? especially in difficult states like OOM?

Actually we catch the exception, but we write it in the log - probably that's what we see.

my app catches own exception by  Thread.setDefaultUncaughtExceptionHandler(...) - it just logges the exception in there and finishes (see my sample at https://github.com/emdete/ItsDown/blob/master/mapsforge/01.getting_started/src/main/java/org/pyneo/android/gui/Sample.java#L41), may that be the cause?

Indeed you want to finish the activity at every exception? (even if a library handles it)

BTW search can reveal many opinions about the use of such ways for globally handling exceptions.

i use the mapsforge default as far as i know - is it enabled in the 0.6 rc?

No, we go with stable multi-threaded off.

--
Emux

[M. Dietrich]

Am Dienstag, 24. November 2015 18:52:43 UTC+1 schrieb Emux:

On 24/11/2015 07:36 μμ, M. Dietrich wrote:

Am Dienstag, 24. November 2015 01:13:36 UTC+1 schrieb Ludwig:

The exception is caught and ignored.

may it be an exception during exception processing? especially in difficult states like OOM?

Actually we catch the exception, but we write it in the log - probably that's what we see.

i do not know because it's not logged ;) i would suggest to log a message like "catched and ignored the following exception: " to be sure what happens...?

my app catches own exception by  Thread.setDefaultUncaughtExceptionHandler(...) - it just logges the exception in there and finishes (see my sample at https://github.com/emdete/ItsDown/blob/master/mapsforge/01.getting_started/src/main/java/org/pyneo/android/gui/Sample.java#L41), may that be the cause?

Indeed you want to finish the activity at every exception? (even if a library handles it)

no, for sure not on every exception. the code  just gets activated when an exception is not catched and would terminate the app. 

BTW search can reveal many opinions about the use of such ways for globally handling exceptions.

my code just loggs the exception and terminates the app. most discussions are about further stuff like using the gui to talk to the user which i prevent. my main goal is to log the exception with the correct logger for the app.

my idea is as follows:

  - the app runs into an OOM

 - my code runs to work on that uncaught exception

 - another exception is caught either during logging or finish()

 - the app is terminated without logging by logger (i filter for that logger) so i don't see it

that would explain why i don't see the cause for the termination and the stacktraces are as you said just logged (please add a message).

what du you think? i will check to filter by pid tomorrow to get such a termination...

[M. Dietrich]

this is the log by pid. it shows a OOM during OOM exception processing:

11-25 11:25:32.794 I/art     (10722): Clamp target GC heap from 272MB to 256MB

11-25 11:25:32.794 I/art     (10722): Alloc concurrent mark sweep GC freed 0(0B) AllocSpace objects, 0(0B) LOS objects, 0% free, 256MB/256MB, paused 1.030mstotal 235.662ms

11-25 11:25:32.794 E/art     (10722): Throwing OutOfMemoryError "Failed to allocate a 28 byte allocation with 0 free bytes and 3GB until OOM" (recursive case)

11-25 11:25:32.794 I/art     (10722): WaitForGcToComplete blocked for 233.124ms for cause Alloc

11-25 11:25:32.806 E/art     (10722): "pool-5-thread-1" prio=5 tid=17 Runnable

11-25 11:25:32.806 E/art     (10722):   | group="main" sCount=0 dsCount=0 obj=0x32c07580 self=0xaec6b400

11-25 11:25:32.806 E/art     (10722):   | sysTid=10791 nice=0 cgrp=default sched=0/0 handle=0xaec72480

11-25 11:25:32.806 E/art     (10722):   | state=R schedstat=( 0 0 0 ) utm=14431 stm=204 core=3 HZ=100

11-25 11:25:32.806 E/art     (10722):   | stack=0x9ff06000-0x9ff08000 stackSize=1036KB

11-25 11:25:32.806 E/art     (10722):   | held mutexes= "mutator lock"(shared held)

11-25 11:25:32.806 E/art     (10722):   at org.mapsforge.core.util.MercatorProjection.getPixelRelative(MercatorProjection.java:161)

11-25 11:25:32.806 E/art     (10722):   at org.mapsforge.core.util.MercatorProjection.getPixelAbsolute(MercatorProjection.java:148)

11-25 11:25:32.806 E/art     (10722):   at org.mapsforge.map.layer.renderer.PolylineContainer.getCoordinatesAbsolute(PolylineContainer.java:83)

11-25 11:25:32.806 E/art     (10722):   at org.mapsforge.map.layer.renderer.PolylineContainer.getCoordinatesRelativeToTile(PolylineContainer.java:94)

11-25 11:25:32.806 E/art     (10722):   at org.mapsforge.map.layer.renderer.CanvasRasterer.drawShapePaintContainer(CanvasRasterer.java:154)

11-25 11:25:32.806 E/art     (10722):   at org.mapsforge.map.layer.renderer.CanvasRasterer.drawWays(CanvasRasterer.java:61)

11-25 11:25:32.806 E/art     (10722):   at org.mapsforge.map.layer.renderer.DatabaseRenderer.executeJob(DatabaseRenderer.java:149)

11-25 11:25:32.806 E/art     (10722):   at org.mapsforge.map.layer.renderer.MapWorkerPool$MapWorker.run(MapWorkerPool.java:121)

11-25 11:25:32.806 E/art     (10722):   at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)

11-25 11:25:32.806 E/art     (10722):   at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)

11-25 11:25:32.806 E/art     (10722):   at java.lang.Thread.run(Thread.java:818)

11-25 11:25:33.073 I/art     (10722): Alloc concurrent mark sweep GC freed 3720661(119MB) AllocSpace objects, 0(0B) LOS objects, 10% free, 136MB/152MB,paused 1.376ms total 279.156ms

11-25 11:25:33.074 I/art     (10722): WaitForGcToComplete blocked for 261.925ms for cause Alloc

11-25 11:25:33.074 E/System  (10722): Uncaught exception thrown by finalizer

11-25 11:25:33.075 W/art     (10722): Long monitor contention event with owner method=void org.mapsforge.map.layer.queue.JobQueue.remove(org.mapsforge.map.layer.queue.Job) from JobQueue.java:84 waiters=3 for 114ms

11-25 11:25:33.082 E/org.pyneo.tabulae(10722): error e=java.lang.OutOfMemoryError: OutOfMemoryError thrown while trying to throw OutOfMemoryError; no stackavailable

11-25 11:25:33.082 E/org.pyneo.tabulae(10722): java.lang.OutOfMemoryError: OutOfMemoryError thrown while trying to throw OutOfMemoryError; no stack available

11-25 11:25:33.091 E/System  (10722): java.lang.OutOfMemoryError: Failed to allocate a 36 byte allocation with 0 free bytes and 3GB until OOM

11-25 11:25:33.091 E/System  (10722):   at java.lang.ref.FinalizerReference.add(FinalizerReference.java:54)

11-25 11:25:33.091 E/System  (10722):   at com.android.internal.os.BinderInternal$GcWatcher.finalize(BinderInternal.java:66)

11-25 11:25:33.091 E/System  (10722):   at java.lang.Daemons$FinalizerDaemon.doFinalize(Daemons.java:191)

11-25 11:25:33.091 E/System  (10722):   at java.lang.Daemons$FinalizerDaemon.run(Daemons.java:174)

11-25 11:25:33.091 E/System  (10722):   at java.lang.Thread.run(Thread.java:818)

11-25 11:25:33.135 E/MapFile (10722): lseek failed: EBADF (Bad file number)

[Ludwig]

Is this on a real device or an emulator?

I ask this because while it is not so super difficult to generate OOM errors on emulators, I do not actually see them on real devices nor do I get any OOM reports via Google Play. 

I think this is because actual user input is not as fast as one can generate it on an emulator (relative to emulator speed).

Ludwig

--
You received this message because you are subscribed to the Google Groups "mapsforge-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapsforge-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/76a25903-2d7d-4beb-95d7-462130d1537c%40googlegroups.com.

[M. Dietrich]

Am Mittwoch, 25. November 2015 15:59:15 UTC+1 schrieb Ludwig:

Is this on a real device or an emulator?

i test on a real device only currently. i have OOMs very, very often. my app is not using that much memory as it's not fully done (i wonder how full blown apps can use mapsforge anyway). do i something wring in the mapsforge usage? can something be done to reduce mapsforges memory hunger?

[Emux]

To complement Ludwig here, the era of 0.3.X was easy to see OOM by overloading the map with overlays (or list overlays).

Now even that we use a square frame buffer, the OOM are extremely very rare.
So first I would check any app implementation (e.g. activity leaks) and mapsforge integration (proper exits with clear).

--
Emux

[Ludwig]

Multiple layers will still need more memory, particularly if you are using transparent layers. (Overlays, as Emux points out, are cheap today).

Are you using multiple layers?

Ludwig

--

You received this message because you are subscribed to the Google Groups "mapsforge-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapsforge-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/56560C75.3070402%40gmail.com.

[M. Dietrich]

Am Donnerstag, 26. November 2015 00:45:24 UTC+1 schrieb Ludwig:

Are you using multiple layers?

no, not  simultaneously. my app allows to switch layers but destroys the old one. the OOM happens even without switching layers.