This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

BaseCamp longtime crash problem

Former Member over 9 years ago

Hey guys,

I've been using Basecamp (with eTrex10) for a long time and right from the beginning I've had stability issues.

Starting on OSX 10.8 and (I think) BaseCamp 4.2.x (first version I was using), I get crashes about 19 times out of 20 when I either select a track and choose "View in Google Earth" or "Export selected data" (the two main functions I use Basecamp for).

Upgrading to 10.9.5 and Basecamp 4.4.7 (latest version), I still get the same behaviour. I just updated to Yosemite and again I still get the same behaviour. I've done all the obvious things, including completely trashing the app and all user data and preferences, reinstalling from scratch. I don't even need to restore my data - creating a quick track in BaseCamp after a vanilla install and selecting "View in Google Earth" will cause the same crash. Frustrating.

So I installed Basecamp 4.4.7 onto a different Yosemite machine, 10.10.3, restored my data into it, and the app does not crash on this machine, it performs as expected. That has 4GB of RAM, my main Macbook Pro (mid-2011) has 16GB.

The crashes are pretty much all the same, here's a crashlog except (I won't post the full thing here unless a dev specifically wants me to - I have been submitting crashlogs via CrashReporter):

--

Process: BaseCamp [2773]
Version: 4.4.7 (4.4.7)
Code Type: X86 (Native)
Parent Process: ??? [1]
Responsible: BaseCamp [2773]

Date/Time: 2015-05-13 16:08:54.649 +0100
OS Version: Mac OS X 10.10.3 (14D136)
Report Version: 11
Anonymous UUID: A14C189E-5502-A159-CF25-89135AD6530D

Time Awake Since Boot: 7300 seconds

Crashed Thread: 27 Dispatch queue: TFSVolumeInfo::GetSyncGCDQueue 0

Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00000000fefff000

VM Regions Near 0xfefff000:
Stack 00000000bf76c000-00000000bff6c000 [ 8192K] rw-/rwx SM=COW
--> VM_ALLOCATE 00000000fefff000-00000000ff000000 [ 4K] rw-/rwx SM=COW
VM_ALLOCATE 00000000ffc00000-00000000ffc24000 [ 144K] rwx/rwx SM=PRV

Application Specific Information:

-- Export selected data crash:
Performing @selector(exportSelectedList:) from sender NSMenuItem 0x7aabbe80

-- View in Google Earth crash
Performing @selector(viewInGoogleEarth) from sender NSMenuItem 0x7f232770

Time: 16:07
Web app
Resident Memory: 1728MB, Virtual Memory: 64MB
Current Map: Global Map
Locale: en
Activity: Switching to Global Map

--

I'd love to be able to use BaseCamp without frustration. It's been like this for years now.
Anything else I can do?

0 Former Member over 9 years ago

This fixed my Problem

Glad you fixed your issue with corrupt data, but note that this is nothing to do with the issues in this thread (which I still haven't found a solution for).

I have noticed that the "View in Google Earth" option from the main menu seems to crash my Basecamp less than the same item chosen from the local menu (ie, right-clicking on an item, and choosing View in Google Earth).

So, one workaround is to use the main menu and avoid the local menus as much as possible - it doesn't fix the crash, it just happens a lot less for me.

0 Former Member over 9 years ago

Hey, just to mention that I am having tons of crashes with BaseCamp, too. MBP retina with 16GB of RAM though I wouldn't think the RAM sizes is related.

Basically, BC continually crashes during usage, sometimes when zooming, panning the map, sometimes when exporting data, very often when quitting the program. I would add, however, that this is just how I use BC so these are the functions causing crashes for me. I am using BC mostly for route creation and for a regular 100k bike ride it usually crashes at least a handful of times, forcing me to redo the last points in the route I was currently creating. I would say that BC is *BY FAR* the most crash-prone program. Like desperable I have used all sorts of workarounds to no avail. It's astonishing to see users on OS X experiencing no crashes at all.

0 Former Member over 9 years ago

Thanks for the info adeu - so maybe it's not exactly one particular bug I'm experiencing, but just a general program instability that's showing up in a particular way for me, a different way for you, and others maybe don't encounter it at all in the way they use the app.

It's a shame as if it worked well it would be a great solution...

0 Former Member over 9 years ago

Same thing is happening to me. new MBP retina, 16GB RAM. Basecamp, in the past, had always worked well.

0 Wurth over 9 years ago

Quick post to let you know that we are looking into these crashes. My initial feeling is that we are running out of memory. BC is a 32-bit app and it looks like most of the related crashes are happening when BC nears 4GB. We haven't been able to reproduce these crashes yet, so it would be helpful if anyone can monitor BC memory use in Activity Monitor and let us know how much memory is being consumed before a crash occurs. Also let us know if you're able to figure out what activities you're doing that increases BC memory consumption. Any help is greatly appreciated. Thank you!

0 JaVaWa over 9 years ago

BaseCamp is displaying more than 1000 tracks at the same time, I'm zooming, panning and calculating routes, but BC won't use more than approx 1 GB.
Maybe it's indirectly related to Retina screens, i.e. it's using much more memory than on non-Retina Macs? (like mine). Could make sense, because a Retina screen has 4 times the number of pixels...

0 Former Member over 9 years ago

Quick post to let you know that we are looking into these crashes.

*Really* appreciate you coming here to look at this. I, and I'm sure others here, are willing to work with you to do what we can to help you get to the bottom of things.

My initial feeling is that we are running out of memory. BC is a 32-bit app and it looks like most of the related crashes are happening when BC nears 4GB. We haven't been able to reproduce these crashes yet, so it would be helpful if anyone can monitor BC memory use in Activity Monitor and let us know how much memory is being consumed before a crash occurs. Also let us know if you're able to figure out what activities you're doing that increases BC memory consumption. Any help is greatly appreciated. Thank you!

Ok, I will do a bit of testing and see if I can deduce anything. Certainly the rather sporadic nature of the crashes suggests something along those lines.

Edit: As a quick test, I quit a bunch of apps, reorganised the Mac's memory, and ran BC. It's using 119MB of memory according to Activity Monitor. I don't have a huge amount of data in BC, maybe 20-30 tracks. I select one, right-click, and select "View in Google Earth". GE runs (doesn't get any data), but BC crashes. It was still using 119MB of memory at the time.

Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00000000fefff000

VM Regions Near 0xfefff000:
Stack 00000000bf77a000-00000000bff7a000 [ 8192K] rw-/rwx SM=COW
--> VM_ALLOCATE 00000000fefff000-00000000ff000000 [ 4K] rw-/rwx SM=COW
VM_ALLOCATE 00000000ffc00000-00000000ffc02000 [ 8K] rwx/rwx SM=PRV

Application Specific Information:
Performing @selector(viewInGoogleEarth) from sender NSMenuItem 0x7967f940
Time: 12:27
Web app
Resident Memory: 3040MB, Virtual Memory: 640MB
Current Map: Global Map
Locale: en
Activity: Switching to Global Map

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 ??? 0xfefff000 0 + 4278185984
1 com.apple.LaunchServices 0x92a7cbda _LSAddRecentNode + 213
2 com.apple.LaunchServices 0x92ae9b7e _LSLaunch(LSContext*, FSNode*, unsigned long, void*, __CFArray const*, AEDesc const*, __CFArray const*, __CFDictionary const*, unsigned long, audit_token_t const*, ProcessSerialNumber*, unsigned char*) + 12361
3 com.apple.LaunchServices 0x92aea5d4 _LSOpenApp(LSOpenState*, unsigned long, FSNode*, unsigned long, unsigned char*, ProcessSerialNumber*) + 320
4 com.apple.LaunchServices 0x92a7547b _LSOpenItemsWithHandler_CFDictionaryApplier(void const*, void const*, void*) + 608

Ran it again, (same 118MB or so displayed in Activity Monitor) but went into the "Info" for the process:
Real memory: 146MB
VM: 980 MB
Shared: 67.8 MB
Private: 89.7 MB

And again, choosing any track and doing the same "View in GE" procedure results in the same crash.

Note - I do not get the same behaviour on a different iMac, running Yosemite, 8GB, on the exact same data. That does not crash and performs much more stable. It's just my 16GB machine.

0 Former Member over 9 years ago

Maybe it's indirectly related to Retina screens, i.e. it's using much more memory than on non-Retina Macs? (like mine). Could make sense, because a Retina screen has 4 times the number of pixels...

I do not have a retina display, I have an MBP with higher res matte display, running 1680x1050.
So at least my crashes probably aren't as a result of a retina display.

0 Wurth over 9 years ago

Same thing is happening to me. new MBP retina, 16GB RAM. Basecamp, in the past, had always worked well.

There's very few retina displays in the office, so I tried this on my home MBP retina system and found the memory consumption go way up when I was just zooming in and out and panning around. I even got a crash. We'll look into our map caching to see what can be done.

0 Wurth over 9 years ago

*Really* appreciate you coming here to look at this. I, and I'm sure others here, are willing to work with you to do what we can to help you get to the bottom of things.

Ok, I will do a bit of testing and see if I can deduce anything. Certainly the rather sporadic nature of the crashes suggests something along those lines.

Edit: As a quick test, I quit a bunch of apps, reorganised the Mac's memory, and ran BC. It's using 119MB of memory according to Activity Monitor. I don't have a huge amount of data in BC, maybe 20-30 tracks. I select one, right-click, and select "View in Google Earth". GE runs (doesn't get any data), but BC crashes. It was still using 119MB of memory at the time.

Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00000000fefff000

VM Regions Near 0xfefff000:
Stack 00000000bf77a000-00000000bff7a000 [ 8192K] rw-/rwx SM=COW
--> VM_ALLOCATE 00000000fefff000-00000000ff000000 [ 4K] rw-/rwx SM=COW
VM_ALLOCATE 00000000ffc00000-00000000ffc02000 [ 8K] rwx/rwx SM=PRV

Application Specific Information:
Performing @selector(viewInGoogleEarth) from sender NSMenuItem 0x7967f940
Time: 12:27
Web app
Resident Memory: 3040MB, Virtual Memory: 640MB
Current Map: Global Map
Locale: en
Activity: Switching to Global Map

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 ??? 0xfefff000 0 + 4278185984
1 com.apple.LaunchServices 0x92a7cbda _LSAddRecentNode + 213
2 com.apple.LaunchServices 0x92ae9b7e _LSLaunch(LSContext*, FSNode*, unsigned long, void*, __CFArray const*, AEDesc const*, __CFArray const*, __CFDictionary const*, unsigned long, audit_token_t const*, ProcessSerialNumber*, unsigned char*) + 12361
3 com.apple.LaunchServices 0x92aea5d4 _LSOpenApp(LSOpenState*, unsigned long, FSNode*, unsigned long, unsigned char*, ProcessSerialNumber*) + 320
4 com.apple.LaunchServices 0x92a7547b _LSOpenItemsWithHandler_CFDictionaryApplier(void const*, void const*, void*) + 608

Ran it again, (same 118MB or so displayed in Activity Monitor) but went into the "Info" for the process:
Real memory: 146MB
VM: 980 MB
Shared: 67.8 MB
Private: 89.7 MB

And again, choosing any track and doing the same "View in GE" procedure results in the same crash.

Note - I do not get the same behaviour on a different iMac, running Yosemite, 8GB, on the exact same data. That does not crash and performs much more stable. It's just my 16GB machine.

Do you have the latest GE version installed? There were reports of BC crashing earlier in the year when launching BC because Google stopped supporting something in the desktop GE API. However, when I looked into this last week I didn't have any problems. Windows BC used to have problems as well, but now they're running just fine after updating to the latest GE.