PDA

View Full Version : Crashes at least once per use


bazutti
October 25th, 2016, 09:47 AM
Sorry but this is mainly a venting thread.

Saved a link? It might crash. Tried looking at a smart image (below the image restriction size)? It might crash. Save a topic? It might crash.

The annoyance of this software, including the time to get back to where you were after a crash, is beginning to outweigh the pros of using it. As I've been using it much heavier lately, I'm noticing more and more about this that makes it from how it first appeared (awesome campaign management) to how it appears now (clunky software that's buggy).

The lack of hotkeys for some functions just drags this down into a larger time sink than is necessary. The save and load times for images and stat blocks could be better as well. The lack of sorting options when viewing topics makes it difficult to always find what you want. Why can't we sort with prefixes or suffixes? Why can't I manually arrange the items?

The smart map is cool until anything else is needed for the image. Ideally, it would gain functionality if I can use some basic drawing tools to mark up the map, and the option to hide the markings.

When making links, it'd be great to see "Ignore rest of snippet" for a given link. It'd be nice to create link stubs without having to click through a bunch of things to create a shell item that's linked now and can be filled out later (think Wiki).

I still think this software has a good use, but it's becoming more difficult and annoying to work with. The bells and whistles are nice to have, but honestly I'm really considering scaling back my "wants" and just using Evernote or One Note again. /rant

Exmortis
October 25th, 2016, 11:26 AM
Link crashes seem to be only happen when I do them manually, not when the system auto detects them. I have submitted a ton of crash reports over the past months with so many modules I have entered.

Like gaming, the trick is to save often, this means you have less lost work on a crash. I save a lot now, and a crash loses me very little. I also re-index the database every few major work times. This has reduced the crashes with links.

Trust me I do feel your pain, I am about to embark on my biggest project yet, and that is saying something after putting the finishing touches on T1-4 Temple of Elemental Evil.

MNBlockHead
October 25th, 2016, 12:29 PM
The only time RW crashes is when I have lots of tabs open, and then try to open a large image. This means that it tends to crash in game. I'm now better about resizing images and breaking up maps rather than trying to have a huge map with hundreds of pins and RW has been much more stable for me.

Acenoid
October 25th, 2016, 12:57 PM
I agree there are some crashes. Links crash only for me nowadays ( I think) if Iam trying to do thinks fast. E.g. clicking multiple times on OK while the previous dialogue window has not completely finished processing. Maybe you can avoid some other crashes too.

Be sure to submit bug reports. If it's frustrating you, best to stop using until the next release which is scheduled soon. Hopefully it will include fixes for the bug reports that were submitted in the past weeks and months.

I think the pro's outweigh the con's even with some crashes and instability.

The suggestions belong into the feature request thread. And here I agree with you as well, there is some functionality missing, but compared to the initial smart images, there are already improvements. I made some suggestions as well regarding the available tool set and I hope that LWD will put everything in :D

MaxSupernova
October 25th, 2016, 07:20 PM
>I'm really considering scaling back my "wants"

Funny, that's almost exactly what the devs just said about what they're delivering.

wurzel
October 25th, 2016, 10:43 PM
During gaming sessions my players start betting on the number of crashes happening. To be honest so far it was never more than three times in a single session but it still prevents some of them who are DMing themselves from licensing RW.
The crashes are almost always Out Of Memory exceptions. Since after the crash the program starts with exactly the same situation and does not crash for some time this strongly hints at poor memory management. But memory leaks are almost always hard to find (I don't know C# but I don't think it is any better in this area than other languages) and therefore I fear that this is going to continue to annoy me.

Farling
October 25th, 2016, 11:53 PM
During gaming sessions my players start betting on the number of crashes happening. To be honest so far it was never more than three times in a single session but it still prevents some of them who are DMing themselves from licensing RW.
The crashes are almost always Out Of Memory exceptions. Since after the crash the program starts with exactly the same situation and does not crash for some time this strongly hints at poor memory management. But memory leaks are almost always hard to find (I don't know C# but I don't think it is any better in this area than other languages) and therefore I fear that this is going to continue to annoy me.

Are you using massive pictures to cause this? I've not had crashes during GMing for a long time.

daplunk
October 25th, 2016, 11:56 PM
I don't think I have ever crashed in a session. The only time it crashes is when I'm messing with massive files (images) and it's rare. Might get 1 crash a month on average.

Crashed 3 times today. But i was doing the same thing over and over again indicating there's a problem with what i'm trying to do not with the application itself so to speak.

rob
October 26th, 2016, 12:36 AM
As was surmised above, the only reason you should be randomly crashing with any frequency is that you are using excessively large images and/or keeping lots of tabs open, usually with images in many/all of them.

The first thing to do is check the resolution of images you're using. If you have 300dpi scans from books, that's usually WAY too big for use on the screen. You should only be using as much resolution as you truly need to zoom into. Anything more is just going to chew up memory unnecessarily (and probably lots of it).

Another possibility is to assess how many different images you're keeping up at one time. Each image consumes its own chunk of RAM. Smart images are the worst, since we have to manage the image, the overlay, the reveal layer, and another layer with all the pins - plus the final composited result. So a single smart image is very expensive. If you have multiple smart images open, you're chewing up memory. If those smart images are unnecessarily large (i.e. resolution), then you're multiplying that excess by FIVE every time. So it's very important to not be wasteful with smart images.

Hopefully, this is helpful. If you investigate and address these issues, you should find yourself running pretty smoothly like others here have said. If you address these and still have problems, let us know. We can continue to brainstorm what might be going wrong for you and see if there are further things to investigate as a cause.

Exmortis
October 26th, 2016, 05:40 AM
As was surmised above, the only reason you should be randomly crashing with any frequency is that you are using excessively large images and/or keeping lots of tabs open, usually with images in many/all of them.

The first thing to do is check the resolution of images you're using. If you have 300dpi scans from books, that's usually WAY too big for use on the screen. You should only be using as much resolution as you truly need to zoom into. Anything more is just going to chew up memory unnecessarily (and probably lots of it).

Another possibility is to assess how many different images you're keeping up at one time. Each image consumes its own chunk of RAM. Smart images are the worst, since we have to manage the image, the overlay, the reveal layer, and another layer with all the pins - plus the final composited result. So a single smart image is very expensive. If you have multiple smart images open, you're chewing up memory. If those smart images are unnecessarily large (i.e. resolution), then you're multiplying that excess by FIVE every time. So it's very important to not be wasteful with smart images.

Hopefully, this is helpful. If you investigate and address these issues, you should find yourself running pretty smoothly like others here have said. If you address these and still have problems, let us know. We can continue to brainstorm what might be going wrong for you and see if there are further things to investigate as a cause.

I never work with more than three tabs while entering my work. One for the topic I am entering, one for the Map (they are not Hi res by any means, I thik the largest is under a MB usually) and one for supporting topic if and when needed.

My crashes almost always come from setting links.

Example, I entered in a new adventure, T1-4 Temple of Elemental Evil. Now anyone who is familiar with this, knows how large it is.

I went back, entered in a topic for every monster in the adventure. Went back to every topic, and created links to the encountered monster to the monster topic. I also went back to all the GM and Player synopsis topics and created a link to every topic mentioned in the text. Example would be in GM notes, specific talk of specific places, encounters etc.

I probably crashed a dozen times or more while doing so. I usually narrowed it down to a specific topic I was linking too. The fixes were either one of the following or both:

1- re indexing the realm.
2- going into the topic, then closing the tab. No saving, no work change, just a simple access of the topic.

The link would then not cause a crash.

This happens on my Surface Pro 4, My Gamer Lappy, and my power desktop. So it isn't install or hardware specific. All are windows 10 however.

There isn't a memory issue, unless RW has a leak like Niagara falls. It can happen within a short time of launching, and often I am going back and merely setting links within GM synopsis topics to actual adventure content entered after. Thus I only have a single tab open.

Trust me I love RW, but it does make me wonder why it wasn't a 64bit application from the get go. :)

jsawdey
October 26th, 2016, 06:44 AM
The few times that RW has crashed on me, it has always been while manually creating links.

Just some extra information that hopefully leads to a fix. I have submitted the same via the crash reports when it has happened.

adzling
October 26th, 2016, 07:41 AM
Oddly even though I run Realmworks under Parallels in osX Realmworks rarely crashes on me.

Overall pretty solid.

However I do agree with the OP re: poor interface.

It's clunky and poorly implemented imho and it does cause problems with entering, managing and using the data.

MaxSupernova
October 26th, 2016, 08:25 AM
Can I just point out that while using smaller images is a good idea, and can prevent the crash, *crashing because the user does something normal that you let him do is not right*.

Saying "Well, if you use smaller images and things are good, then we're good, otherwise let us know" is not an acceptable official response.

It shouldn't be up to the user to prevent program crashes, especially using functionality that easily allows it.

bazutti
October 26th, 2016, 09:02 AM
Can I just point out that while using smaller images is a good idea, and can prevent the crash, *crashing because the user does something normal that you let him do is not right*.

Saying "Well, if you use smaller images and things are good, then we're good, otherwise let us know" is not an acceptable official response.

It shouldn't be up to the user to prevent program crashes, especially using functionality that easily allows it.

I agree 100%. And my images are smaller than the size they restrict us to (don't remember the exact dimensions but roughly 4000x3000 is their limit). I'm ok with the limit, but don't tell me afterwards that "Oh, well you should use smaller than that, tailor everything to the scale or your world, etc". If I have a world building tool, it should allow me to do just that and it should be able to handle things when the world expands.

Vargr
October 26th, 2016, 09:31 AM
The lack of sorting options when viewing topics makes it difficult to always find what you want. Why can't we sort with prefixes or suffixes?

This can be done. Enter a suffix for the topics in question. A simple 1, 2, 3, etc would do.

Go to the wrench the upper left corner (next to the search button).
Select "sort topics by prefix".
The topics are now sorted by prefix - and if they have no prefix then alphabetically.

I use this a lot when working with hierarchies, for example an army (so the major is above the lieutenant).

Why can't I manually arrange the items?

Well, it is not possible at the moment.

But it would be useful!

The smart map is cool until anything else is needed for the image. Ideally, it would gain functionality if I can use some basic drawing tools to mark up the map, and the option to hide the markings.

Nice idea - suggest it in the features forum.

It isn't anything I have missed yet, but we all use RW differently.

It'd be nice to create link stubs without having to click through a bunch of things to create a shell item that's linked now and can be filled out later (think Wiki).

This can be done.

When you a busy writing a topic about the main antagonist and his childhood and suddenly realise, that you probably would need a topic on the poor village in the mountains from which he hails, you simply press CTRL+Q and fill in the barest of info regarding the new topic and press OK. You then continue on with the topic at hand and can later fill out the details of the topic you made "on the run".

You can also highlight a word or several in a topic, press CTRL+Q and quickly make a new topic where the name will already be filled out based on your highlightning.

I still think this software has a good use, but it's becoming more difficult and annoying to work with. The bells and whistles are nice to have, but honestly I'm really considering scaling back my "wants" and just using Evernote or One Note again. /rant

I do not know why you have so many crashes and other - smarter - people than me have tried to help out above.

Before RW I was using paper, binders, word processors, Evernote and a myriad of other more or less useful programs on at least three completely different computer systems for making my world in.

I am not likely to ever go back to them; RW does it so much better (IMHO). If you can sort out the crash problem see if you can give RW another go - I think there is a chance it will grow on you :-)

Exmortis
October 26th, 2016, 11:27 AM
I think there is a chance it will grow on you :-)

**WARNING**

RW will grow on you like a fungus. I cant imagine, don't want to imagine, will never imagine a campaign not managed within RW.

wurzel
October 27th, 2016, 04:18 PM
As was surmised above, the only reason you should be randomly crashing with any frequency is that you are using excessively large images and/or keeping lots of tabs open, usually with images in many/all of them.

The first thing to do is check the resolution of images you're using. If you have 300dpi scans from books, that's usually WAY too big for use on the screen. You should only be using as much resolution as you truly need to zoom into. Anything more is just going to chew up memory unnecessarily (and probably lots of it).

Another possibility is to assess how many different images you're keeping up at one time. Each image consumes its own chunk of RAM. Smart images are the worst, since we have to manage the image, the overlay, the reveal layer, and another layer with all the pins - plus the final composited result. So a single smart image is very expensive. If you have multiple smart images open, you're chewing up memory. If those smart images are unnecessarily large (i.e. resolution), then you're multiplying that excess by FIVE every time. So it's very important to not be wasteful with smart images.

Hopefully, this is helpful. If you investigate and address these issues, you should find yourself running pretty smoothly like others here have said. If you address these and still have problems, let us know. We can continue to brainstorm what might be going wrong for you and see if there are further things to investigate as a cause.

That makes sense. I usually have many tabs and pictures open, and the maps have a rather high resolution so we can zoom in during play.

But still: Windows resource manager shows that RW is using approximately 400-500 MB of the main memory when the exception occurs, leaving several GB of free memory. So the image size and number of tabs should not make a difference even if it is a 32 bit application.

And the other mystery remains: at startup after the crash RW comes up with exactly the same number of tabs and images open. The only difference is that the offending action that led to the exception now runs smoothly.

There is just one explanation that comes to my mind. The restart causes some kind of garbage collection, orphaned memory allocations are freed, and the opened content is somehow reorganized in the main memory. For me this strongly hints at some improvements of memory management which should be made.

But maybe there are other reasons for this behaviour. Although my time in IT is over and I'm just a simple housewife now I'd still be interested which reasons that might be.

kbs666
October 28th, 2016, 09:56 AM
I can think of several.

First you could be right. If RW is in part or whole written under C#, or equivalent, it has garbage collection which is known to be less than perfect. If nothing triggers a GC sweep for a while and the VM in question runs out of resources it could certainly crash.

Second it could be a failure of the OS to properly release resource handles. If it isn't a managed application this would be my most likely suspicion. Having lots of images open means lots of resource handles. Windows is supposed to be able to allocate many millions of handles but IME it doesn't always release all the ones it should and that can lead to problems either with resource allocation or with memory leaks if big images wind up sitting around in memory when no longer needed.

In either case this would be outside the control of LWD. While they could take steps to try and minimize the problem once identified the problem is in the OS.

Big images causing the problem could also point to a graphic card problem. If the card overheats that could cause an exception of a sort the program would not be able to recover from. A shutdown and restart would be enough of a drop in load to let the card cool off so it is a possible but unlikely culprit as well.

rob
October 30th, 2016, 01:19 PM
Can I just point out that while using smaller images is a good idea, and can prevent the crash, *crashing because the user does something normal that you let him do is not right*.

Saying "Well, if you use smaller images and things are good, then we're good, otherwise let us know" is not an acceptable official response.

It shouldn't be up to the user to prevent program crashes, especially using functionality that easily allows it.

While I concur with this sentiment, it's a LOT harder than you make it sound. And it gets even more complicated because key aspects of this problem are something we have NO control over with C# and .Net. :(

One of the proclaimed advantages of .Net is that you don't have to worry about memory management. In fact, .Net takes it completely out of your hands as a developer. This is convenient in some ways, but it's s a double-edged sword. The moment you need to do lots of efficient work with images, it becomes necessary to utilize "unmanaged" memory. And the collective experiences of users who use lots of large images has been that the unmanaged memory pool readily gets exhausted or fragmented, resulting in an out-of-memory crash.

We've gone through the crash reports we've received with out-of-memory conditions. In the vast majority of cases, it's a result of lots of large images being utilized. For the few other cases, there isn't enough information for us to have a concrete sense of what led to the problem, but they may also have been connected with lots of large images being used.

Unfortunately, the best we can do is monitor and throttle things for users. We've mapped out a mechanism through which we will track what images are being mucked with by users. Once a (hopefully safe) threshold is exceeded, we will simply stop loading more images until the user unloads other images, allowing this issue to be effectively sidestepped. Obviously, we'll also report what happened to the user, why we're doing it, and how the problem can be mitigated.

I'm not sure if we'll be able to get this new mechanism into place for the November (or even December) release. If we add it into either the November of December release, other stuff we had planned to implement will have to be dropped to free up the necessary dev time. Right now, those are some very difficult tradeoffs.

rob
October 30th, 2016, 01:30 PM
My crashes almost always come from setting links.

Example, I entered in a new adventure, T1-4 Temple of Elemental Evil. Now anyone who is familiar with this, knows how large it is.

I went back, entered in a topic for every monster in the adventure. Went back to every topic, and created links to the encountered monster to the monster topic. I also went back to all the GM and Player synopsis topics and created a link to every topic mentioned in the text. Example would be in GM notes, specific talk of specific places, encounters etc.

I probably crashed a dozen times or more while doing so. I usually narrowed it down to a specific topic I was linking too. The fixes were either one of the following or both:

1- re indexing the realm.
2- going into the topic, then closing the tab. No saving, no work change, just a simple access of the topic.

The link would then not cause a crash.

This certainly isn't an out-of-memory bug. This MIGHT be an issue with the name indexing engine, but I have no idea what might be going on. The only way to sort out an indexing issue would be to actually receive your database. We capture "playback" information for the name index within the database. We can pull that out and see if we can recreate the problem that way, which would allow us to locate and fix the issue. Of course, this assumes the issue IS with the indexing engine and not something else.

Please provide us with your database. Attach download information for the database to a support ticket concerning these crashes. And please include as much detail about the steps you're taking within RW that are resulting in the crash.

Please also give us a step-by-step sequence from a point after you've performed a re-index, including the names involved. If this is not an issue with the indexing engine, your step-by-step details will be critical to us figuring out what is going wrong with the linking mechanism.

Thanks!

rob
October 30th, 2016, 01:40 PM
But still: Windows resource manager shows that RW is using approximately 400-500 MB of the main memory when the exception occurs, leaving several GB of free memory. So the image size and number of tabs should not make a difference even if it is a 32 bit application.

Windows often lies about stuff like that. :( Especially when .Net is involved, what the Task Manager shows you is not necessary accurate. All of the out-of-memory crash reports include exact diagnostics of these details, and I think the smallest one showed about 1.4GB of memory allocations when the crash occurred. That total does NOT include the program itself, nor some of the other resources it's utilizing, all of which must fit into slightly less than 2GB of space.

And the other mystery remains: at startup after the crash RW comes up with exactly the same number of tabs and images open. The only difference is that the offending action that led to the exception now runs smoothly.

That strongly implies memory fragmentation. When you start the product anew, all the fragmentation that occurred during the previous run is reset. So the problem doesn't arise after the restart, but it would very likely occur after further use of the product for some amount of time, during which memory fragmentation would again arise.

Exmortis
October 31st, 2016, 05:09 AM
This certainly isn't an out-of-memory bug. This MIGHT be an issue with the name indexing engine, but I have no idea what might be going on. The only way to sort out an indexing issue would be to actually receive your database. We capture "playback" information for the name index within the database. We can pull that out and see if we can recreate the problem that way, which would allow us to locate and fix the issue. Of course, this assumes the issue IS with the indexing engine and not something else.

Please provide us with your database. Attach download information for the database to a support ticket concerning these crashes. And please include as much detail about the steps you're taking within RW that are resulting in the crash.

Please also give us a step-by-step sequence from a point after you've performed a re-index, including the names involved. If this is not an issue with the indexing engine, your step-by-step details will be critical to us figuring out what is going wrong with the linking mechanism.

Thanks!

I will do it later this week. I am busy next few evenings and won't have the time to give you the detail to make it useful.

My database is approaching 600MB so will need info returned to me from ticket for uploading it.

rob
October 31st, 2016, 05:45 AM
I will do it later this week. I am busy next few evenings and won't have the time to give you the detail to make it useful.

My database is approaching 600MB so will need info returned to me from ticket for uploading it.

When you're ready, details on how to get us your database will be found in the following thread, which is stickied at the top of the forums if you should need it again in the future:
http://forums.wolflair.com/showthread.php?t=48663

Thanks!

meek75
November 3rd, 2016, 03:57 AM
So, this conversation has spurred a question for me. I have a system that is chalked full of tables in the game manual. Typically, I find it easier to take a screen snippet of the table and load it as a simple pic in RW. Is this a bad practice? From a memory / realm size stand point am I creating problems that will surface down the road? I think the answer is no, but I thought it was worth asking.

daplunk
November 3rd, 2016, 04:13 AM
I do the same thing. Alot more efficient ;)

Exmortis
November 3rd, 2016, 05:28 AM
I do it a lot as well, especially for map legends that share multiple maps. I will snippet it and add as picture below the maps.

Large complex tables that will take more effort to remake than worth it, I do the same as you meek.

Time vs reward vs efficiency vs value = my work.

Snip tool is my bestest friend.

Exmortis
November 3rd, 2016, 08:49 AM
When you're ready, details on how to get us your database will be found in the following thread, which is stickied at the top of the forums if you should need it again in the future:
http://forums.wolflair.com/showthread.php?t=48663

Thanks!

Submitted report, received case #.
Its long and details the link crash issue and a few minor issues I have observed. I mention it in the case, but to give you a heads up, the most recent heavy work was done in "T1-4 Temple of Elemental Evil" during my QA pass work, so maybe focusing there will help. The Realm "Return to the Elemental Evil" is new and so far not a single crash I remember, but I am not doing much manual linking yet, but I have seen examples of all my minor issues reported.

All realms that have more then just my initial frame work (you will know what I mean when you look) have seen the link/crash issue to some degree. But some of them have not seen recent QA work where I see most of the crashes. "I6 Ravenloft" is new, but I have not yet done any QA, the text paste was less than stellar and I have not yet come to terms with the work to be done, so though new, not really a good candidate for linking issues I have seen, but feel free to have fun in them all!

As per thread I have emailed David for an alternative method to email for my database. even zipped it will not attach to an email.

I am leaving for a funeral so please allow for a few days to get it to you.

Silveras
November 3rd, 2016, 10:27 AM
@Exmortis ... I've used DropBox to get the database file to David before.

rob
November 3rd, 2016, 11:41 AM
So, this conversation has spurred a question for me. I have a system that is chalked full of tables in the game manual. Typically, I find it easier to take a screen snippet of the table and load it as a simple pic in RW. Is this a bad practice? From a memory / realm size stand point am I creating problems that will surface down the road? I think the answer is no, but I thought it was worth asking.

Unless the tables are scanned at overly high resolution, this should be perfectly fine. I assume the table are effectively at around 100dpi, which is appropriate for on-screen viewing. That's not a problem. And you're handling them as picture snippets - not smart images - within the topics, right? If so, then you should be fine on that count as well.

The two big issues are very high resolution for extensive zooming combined with smart images (which entail lots of layers to manage all the aspects). Neither of those are applicable here.

rob
November 3rd, 2016, 11:42 AM
@Exmortis ... I've used DropBox to get the database file to David before.

Or OneDrive, or GoogleDrive, or whatever "free" service you happen to like using... :)

Exmortis
November 5th, 2016, 04:25 AM
Or OneDrive, or GoogleDrive, or whatever "free" service you happen to like using... :)

Free?>"Free"? hehe

I never even considered using my 365 account's Onedrive. But arrived back far to late last night so I just uploaded it, and just shared it via email to David this morning. I live in the sticks so I only have crappy 5/1 service, took serious time to upload an almost 450MB file.

I have more storage in the cloud then I have on my local NAS.