search

J-P-Hanafin / mytracks

Automatically exported from code.google.com/p/mytracks
0 stars 0 forks source link

Forced close required to end track #558

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Start a track with a Zephr heart monitor
2. Leave track in foreground
3. Attempt to save track.

What is the expected output? What do you see instead?
Expected to save the track.  When I tried to get to the menu to save the track, 
my Droid said that I could wait or Force close.  I waited several times but 
finally gave up and force close of the app and created a log file (Gmail - 
Android device log2.htm).  Several hours later, I opened MyTracks and it was 
still recording the track (I don't think the icon was showing that it was still 
recording).  I was VERY surprised.  So I saved that log file too. (Gmail - 
Android device log3.htm)

What version of MyTracks are you using? 1.1.9

On what version of Android? Droid 2.2

On what
phone? Motorola Droid

If possible please provide a log.  Either upload here or send to mytracks-
support@google.com.
Detailed instructions can be found here:
http://code.google.com/p/mytracks/wiki/HowToReportErrors

Please provide any additional information here:  This has happened several 
times with version 1.1.7 and 1.1.8.  In those versions, MyTracks would just 
terminate when I went to save the track.  The track saved okay, but the app 
just terminated.  I did NOT get logs for those but thought they might be 
related.

Original issue reported on code.google.com by bhecht4...@gmail.com on 31 Aug 2011 at 12:52

Attachments:

GoogleCodeExporter commented 9 years ago 
This morning MyTrack had a "forced closed" when I clicked the button to save 
the track.  However, when I restart the app (and unlike yesterday, it started 
by loading in the track as I would expect), it appears to have saved the track. 
 I have attached the log file.

Original comment by bhecht4...@gmail.com on 31 Aug 2011 at 1:11

Attachments:

GoogleCodeExporter commented 9 years ago 
Happened again last night.  Started a new track and left it in the foreground.  
When I arrived at my destination, MyTracks was still in the foreground.  I 
pushed the button to save, but nothing happened until the window opened that 
sid MyTracks is not ressponding.  Waited a while and tried again.  MyTracks was 
still not responding. So I "forced closed" it.  I looked and there was no icon 
showing MyTracks running.  But when I restarted MyTracks, it was still 
recording the track.  I was then able to save the track as normal.

I've attached the log file.

Original comment by bhecht4...@gmail.com on 2 Sep 2011 at 3:31

Attachments:

GoogleCodeExporter commented 9 years ago 
I had this happen to me today as well.  Force close when I stopped recording, 
but the track had been saved and the recording had stopped okay.  Haven't seen 
this previously.  Thought I would add another log in case it helps.

Original comment by jaredcas...@gmail.com on 3 Sep 2011 at 11:28

Attachments:

GoogleCodeExporter commented 9 years ago 
A few of the logs and the dev console have a stack trace like:
ava.util.concurrent.RejectedExecutionException: pool=0/1, queue=0
at 
java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPool
Executor.java:1961)
at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:794)
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1315)
at 
java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java
:85)
at 
java.util.concurrent.Executors$DelegatedExecutorService.submit(Executors.java:61
2)
at 
com.google.android.apps.mytracks.services.TrackRecordingService$1.onLocationChan
ged(TrackRecordingService.java:156)
at 
android.location.LocationManager$ListenerTransport._handleMessage(LocationManage
r.java:227)
at 
android.location.LocationManager$ListenerTransport.access$000(LocationManager.ja
va:160)
at 
android.location.LocationManager$ListenerTransport$1.handleMessage(LocationManag
er.java:176)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:123)
at android.app.ActivityThread.main(ActivityThread.java:3806)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:507)
at 
com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:839)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:597)
at dalvik.system.NativeStart.main(Native Method)

Basically it looks like some of the methods get called after the executor is 
shutdown.  I will move it's shutdown to the end and check the state before we 
execute anything.

Original comment by sandordo...@google.com on 6 Sep 2011 at 3:54

GoogleCodeExporter commented 9 years ago 
A few of the logs and the dev console have a stack trace like:
ava.util.concurrent.RejectedExecutionException: pool=0/1, queue=0
at 
java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPool
Executor.java:1961)
at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:794)
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1315)
at 
java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java
:85)
at 
java.util.concurrent.Executors$DelegatedExecutorService.submit(Executors.java:61
2)
at 
com.google.android.apps.mytracks.services.TrackRecordingService$1.onLocationChan
ged(TrackRecordingService.java:156)
at 
android.location.LocationManager$ListenerTransport._handleMessage(LocationManage
r.java:227)
at 
android.location.LocationManager$ListenerTransport.access$000(LocationManager.ja
va:160)
at 
android.location.LocationManager$ListenerTransport$1.handleMessage(LocationManag
er.java:176)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:123)
at android.app.ActivityThread.main(ActivityThread.java:3806)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:507)
at 
com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:839)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:597)
at dalvik.system.NativeStart.main(Native Method)

Basically it looks like some of the methods get called after the executor is 
shutdown.  I will move it's shutdown to the end and check the state before we 
execute anything.

Original comment by sandordo...@google.com on 6 Sep 2011 at 3:54

GoogleCodeExporter commented 9 years ago 
Rodrigo please review:

http://code.google.com/r/sandordornbush-patches/source/detail?r=60cff0d20b5bc8c5
27050e899b8cf93360287075

Original comment by sandordo...@google.com on 6 Sep 2011 at 9:45

GoogleCodeExporter commented 9 years ago 
Sorry for taking a bit - busy week.

Original comment by rdama...@google.com on 11 Sep 2011 at 10:19

GoogleCodeExporter commented 9 years ago

Original comment by sandordo...@google.com on 19 Sep 2011 at 8:47