Crashing and crashing

[AG]

as reported before inShort crashs while drilling in folders. Meanwile it crashs so often that I stopped working with it. Freeing memory seems to help sometimes, but the situation worsen and I looking desperately for a bug fix.

[shortki]

I would have corrected the situation, but so far I cannot make the program settings work unstable. I tried many things, but no, it still works, and to prescribe a treatment, I desperately need a diagnosis.

[AG]

Thanks for the attention. Is there any constrain on the file size of depth of nesting?

[shortki]

The program has no internal structural constraints, the amount of resources available for the device acting as the natural constraint.

[Julius Max]

Hi,

I'm on iPod Touch.
User guide works.
I created my first folder ok.
I can edit its parameters.
App crashes when I atempt to drill in.
 Black screen for 1 or 2 sec, music stop. Inshort still in opened tasks...

This is very frustrating.

[shortki]

Try running the application after rebooting the device. Memory of applications on iPod is the smallest, cleaning memory may improve the situation.

[gfinlay]

Try running the application after rebooting the device. Memory of applications on iPod is the smallest, cleaning memory may improve the situation.

I have the same problem as Julius Max. The app is basically unusable for me as it crashes as soon as I drill down on the main user manual folder icon.

I have a 4th gen iPod Touch 32MB running iOS 5.1.1. I still crash even after rebooting and immediately cleaning memory using Memory Doctor (Optimize function).
After reboot, Memory Doctor reports that Free is 50.2Mb after optimization (~20% free) with no applications running. Wired is 54.1MB, Active is 58.4MB and Inactive is 32.5 MB. Total memory is 248MB.

Here is the crash dump I got from Settings under General\About\Diagnostics and Usage\Diagnostics & Usage Data...
I choose the most recent dump: "LowMemory-2012-06-07-2245"...

Incident Identifier: 68A4A4A6-9FF3-4957-8389-468EFBE26862
CrashReporter Key:   675b266acc07d8932009ea150903898e45098494
Hardware Model:      iPod4,1
OS Version:          iPhone OS 5.1.1 (9B206)
Kernel Version:      Darwin Kernel Version 11.0.0: Sun Apr  8 21:51:26 PDT 2012; root:xnu-1878.11.10~1/RELEASE_ARM_S5L8930X
Date:                2012-06-07 22:45:51 -0700
Time since snapshot: 58 ms

Free pages:        693
Active pages:      0
Inactive pages:    732
Throttled pages:   34627
Purgeable pages:   0
Wired pages:       27481
Largest process:   tooShort

Processes
         Name                 UUID                    Count resident pages
           amfid <a1d02ed0c7093dcaafe18dcc20a70300>     100
        tooShort <b5aedec4715435a2a29979905a0e4fc4>   30216 (jettisoned) (active)
       securityd <1a3f5034fb623ac896bfd78f6c11ea3f>     157
        networkd <80ba40030462385085b5b7e47601d48d>     108
        sandboxd <a4a51d8f20643075a08fac3308ae8386>     108
     MobilePhone <8f3f3e982d9235acbff1e33881b0eb13>     665 (jettisoned)
      MobileMail <eed7992f4c1d3050a7fb5d04f1534030>     853 (jettisoned)
         notifyd <f6a9aa19d33c3962aad3a77571017958>     160
      aosnotifyd <8cf4ef51f0c635dc920be1d4ad81b322>     383 (jettisoned)
        BTServer <31e82dfa7ccd364fb8fcc650f6194790>     307
CommCenterClassi <041d4491826e3c6b911943eddf6aaac9>     245
     SpringBoard <c74dc89dec1c3392b3f7ac891869644a>   19862 (active)
      aggregated <a12fa71e6997362c83e0c23d8b4eb5b7>     249
            apsd <e7a29f2034083510b5439c0fb5de7ef1>     214
         configd <ee72b01d85c33a24b3548fa40fbe519c>     268
     dataaccessd <473ff40f3bfd3f71b5e3b4335b2011ee>     925 (jettisoned)
   fairplayd.N81 <32fbd294ec02341e8c89570445ba4b67>     111
       fseventsd <914b28fa8f8a362fabcc47294380c81c>     104
            iapd <0a747292a113307abb17216274976be5>     256 (jettisoned)
         imagent <9c3a4f75d1303349a53fc6555ea25cd7>     305
       locationd <cf31b0cddd2d3791a2bfcd6033c99045>     520 (jettisoned)
   mDNSResponder <86ccd4633a6c3c7caf44f51ce4aca96d>     160
    mediaremoted <327f00bfc10b3820b4a74b9666b0c758>     166
    mediaserverd <f03b746f09293fd39a6079c135e7ed00>     541 (jettisoned)
       lockdownd <b06de06b9f6939d3afc607b968841ab9>     179
          powerd <133b7397f5603cf8bef209d4172d6c39>     106
         syslogd <7153b590e0353520a19b74a14654eaaa>      74
           wifid <3001cd0a61fe357d95f170247e5458f5>     220
  UserEventAgent <dc32e6824fd33bf189b266102751314f>     295
         launchd <5fec01c378a030a8bd23062689abb07f>      92

**End**

[Linden]

I have the same problem except that I am using the system on iPad 2 OS 5

It used to work perfectly and then all of a sudden it crashes with almost anything I do - drill down, try to edit text describing a block, etc...

For what it's worth, I do not use the program to model processes, I simply use it to help me build the structure for a novel (I know, different). I have blocks connecting to each other and each block is loaded with text (to describe a chapter, a character or a location). And that is it. I'm not running time dependent models, I'm not looking at critical paths, nothing.

My current diagram has a lot of text blocks and nothing more, yet drilling down, drilling up or editing text crashes the system without fail... (where before it used to work perfectly).

Hope someone can help ...

[shortki]

It looks like the size of the diagram exceeded the capacity of the device to allocate memory. It may be recommended to break one large diagram into several smaller embedded ones.
1. First, reboot the device, this will optimize memory allocation.
2. Then run the application and enable the memory saving mode in the settings.
3. Save the original diagram as an ish-file — it will be a backup copy.
3(a). Try to reduce the size of the items and of the diagram in whole.
4. Then, highlighting various parts of the diagram in the edit mode, activate the drill down feature from the context menu.
5. When the number of items is reduced, group them more compactly and adjust the size of the canvas.

[Linden]

Hi there,

Are you replying to gfinlay or to me or both of us?

My diagram is huge, but with nothing but text per block, shouldn't occupy such a large memory space? (all the text dumped onto a text doc is only a few kb in size). Or does the system allocate a fixed amount of memory / bock or / canvas size?

If so, is there an ultimate number of blocks your system can accomodate nested or otherwise?

Does nesting save or waste memory space?

[shortki]

This answer is for you, the answer to gfinlay was the last update of the application.
The required amount of memory is strongly dependent on the size of the canvas of the current diagram and only slightly dependent on the number of embedded diagrams. Therefore, a large set of related diagrams of an average size is less demanding of memory than a single large one. Also, I came from the fact that diagrams of more than 15 items are difficult to apprehend for a man (the optimum is 7-12).
Memory allocation can be optimized, but at the cost of easy editing, which is undesirable.