bug reports

[Alexey Popov]

I have a few problems. Currently I use last version (3.1.9), but problems have appeared early. 

1. If I click on the thumbnail bar to look on a different pictures too often, after some time (minutes, tens on minutes) Backyard just stop show the pictures. Solution - close application and open it. This is an old problem.  Sometime it start to work after shooting, sometimes not. 

2. Very inconvenient bug. It appear about half of year ago. Time to time Backyard  does not catch last preview picture, recently downloaded from camera. It simply has not appeared in thumbnail bar. At all. But I could find a file on a disk. Currently I "lost" 1 picture from 4-5. Sometime a sequence. Solution - just make a new preview. And again. And again.  Very inconvenient when you should do something fast.  

3. I have no idea how, but when Backyard started, I have some problems with wireless communication (I use laptop): website opens slowly, ping very unstable. As soon as I close Backyard - I have fast internet and no problems with ping and etc. Can`t understand how it possible... 

Backyard 3.1.9, Windows 8.1 Pro 64

 

 

[Alexey Popov]

5 hours ago, admin said:

Okay, thank you for your hard work running those tests.  I really appreciate it.

Regards,

EDIT:  I just ran session plan with 100 pictures and it never got over the 450MB... then drops to about 300MB... goes up, then drops again.  Weird that yours goes close to 800-900

 

Morning! 

Yes, with a new settings I have the same with drag and drop - not more then 500 mb and no lost pictures. But if I start clicking on thumbnails, or clicking and shooting - I got problems 1 and 2. And BYE in this moment use more then 800Mb, up to 1,2 Gb.

I`ll make new video with resource monitor and logs in the evening.  

[admin]

Hope you had a good night sleep

Again forget about clicking the thumbnail.

All I care for now is if you get the same error when taking pictures only, without ever clicking the thumbnail ever. 

Does this make sense? According to your posts you keep clicking the thumbnail when taking images, don't do this.  I need to know if taking images ONLY will also do this.

[Alexey Popov]

16 hours ago, admin said:

Hope you had a good night sleep

Again forget about clicking the thumbnail.

All I care for now is if you get the same error when taking pictures only, without ever clicking the thumbnail ever. 

Does this make sense? According to your posts you keep clicking the thumbnail when taking images, don't do this.  I need to know if taking images ONLY will also do this.

All problems have the same root - memory releasing. Clicking on the thumbnail just one of the way to repeat problem. 

Ok, I made tests. Here is the video and the logs. Its long enough but very interesting! 

https://www.dropbox.com/s/1l6p58ximuyjwis/BYE_2017_04_27.avi?dl=0

https://www.dropbox.com/s/0sy3lpj5t1wh23r/backyardeos_log.7z?dl=0

The tests:

1. I droped 101 pictures I got 3 days ago.  As you can see fast enough I have first out memory error! And exactly in the moment when  BYE memory exceed 1 Gb. After that memory was released and for some time I have no error but as soon used memory reached 1 Gb - out of memory again. Finally I have 100 pictures in thumbnail bar instead of 101.

2. After that I click on it two times (TWO) and started preview shooting. And I got problems. And you can see I got 1 successful shot and then it does not work for a long time until in some moment some memory was released (BYE used memory fall down less then 850 Mb) and I got second successful shot. 

3. After that I closed BYE, started again and touching nothing started preview shooting. As you can see BYE took memory with each shot and after 6 (only SIX!) shots it exceed 900 Mb and that`s all. Game over. Memory was not been released. But after some time it suddenly released and I got 7-th shot! 

The problem is in the memory releasing. 

 

[admin]

What I don't understand is that the memory is released, BYE disposed of ALL images making them available for the GC to reclaim the memory, but on your system is looks the GC is not recycling the memory in time.  What seems to corroborate this is that the memory use does go down eventually suggesting the that GC is doing what it is suppose to but... but at a delay rate.

I'm not sure what to do or suggest aside from from perhaps trying this which was a suggested by astroman133 a few days back.

https://blogs.msdn.microsoft.com/calvin_hsia/2010/09/27/out-of-memory-easy-ways-to-increase-the-memory-available-to-your-program/

 

[Alexey Popov]

Currently I`m 100% sure that problem is in the memory releasing and all 3 problems have the same root. Different libraries do not help. You need to understand why memory is not releasing in time. 

Dispose never release memory, resource only. In this case pictures store in the LOH as generation 2 collection. And it will be released... After some time. But in case memory is not enough GC must release it in the moment when you request memory for the next picture. But it does not. Why? 

Of course I know nothing about architecture of your application, I did no see source code. I just told with my much more experienced colleagues (I left development a few years ago and I do not familiar with .Net) and ask when it happens usual. And the answer is that most often such problems caused by two reasons: 

1) object was not really disposed

2) you have a problems in finalizer. And most often its a deadlock, because finalizer runs in another thread (GC is a multi-thread solutions). Its possible to hang GC completely. 

By the links above there some interesting information about GC and LOH. And there are a lot of information about Finalize(). 

[Alexey Popov]

11 minutes ago, admin said:

What I don't understand is that the memory is released, BYE disposed of ALL images making them available for the GC to reclaim the memory, but on your system is looks the GC is not recycling the memory in time.  What seems to corroborate this is that the memory use does go down eventually suggesting the that GC is doing what it is suppose to but... but at a delay rate.

I'm not sure what to do or suggest aside from from perhaps trying this which was a suggested by astroman133 a few days back.

https://blogs.msdn.microsoft.com/calvin_hsia/2010/09/27/out-of-memory-easy-ways-to-increase-the-memory-available-to-your-program/

 

Yes, this interesting. I did not know about that. But you are looking in the wrong direction. First - check Dispose() and very carefully check Finalize() if you use it. 

[admin]

8 minutes ago, Alexey Popov said:

Yes, this interesting. I did not know about that. But you are looking in the wrong direction. First - check Dispose() and very carefully check Finalize() if you use it. 

Dude, objects ARE disposed.  I've been doing this for over 30 years now!  The issue the GC!!!

[Alexey Popov]

1 minute ago, admin said:

Dude, objects ARE disposed.  I've been doing this for over 30 years now!  The issue the GC!!!

May be we are so lucky to be faced with a bug in GC  But to be honest I do not believe in miracles I believe in statistics and Murphy's law. If it is bug in GC -  it must be on the web. 

Ok, Its time to go to sleep. Right now I do not have more information or ideas. I was very good in debugging without debugger, but not without source code  If you need more tests - you are welcome. 

If you can make a simple test application (just preview function) and give it to me with source code - I can try to do something with it here, where the problem is easy to reproduce. 

[admin]

There is one thing I'm not disposing of, and it is the image displayed in the picturebox once a new image comes in for display.  

I'll try disposing of it just before a new image is displayed, maybe this will help.  I don't get the same error as you do so I can not test/confirm this will help.  For me the GC passes in time and the memory never goes as high as you.

Sorry if it seems like I'm loosing my patience, I re-read my posts and I was a bit harsh with you at times.  I apologize for this 

Regards.

[Alexey Popov]

5 hours ago, admin said:

There is one thing I'm not disposing of, and it is the image displayed in the picturebox once a new image comes in for display.  

I'll try disposing of it just before a new image is displayed, maybe this will help.  I don't get the same error as you do so I can not test/confirm this will help.  For me the GC passes in time and the memory never goes as high as you.

Sorry if it seems like I'm loosing my patience, I re-read my posts and I was a bit harsh with you at times.  I apologize for this 

As Germans say - kein problem I understand, its hard to accept advice when you checked everything hundreds times already, especially if you have 30 years of experience (what makes you blind some time and here I`m talking about myself )  and three times especially from some one unknown parvenu on internet forum  

As I say before I like your product and I would like to work with it, but as you can see - currently its not possible. So I`m highly motivated to help you to fix this problem. If it makes happy another 100 astronomers - it would be twice better

So, what we are waiting for? Just give me new version and we will find out does it help or not very fast! :)  

The question is when you call dispose for the old picture? Right after the new one has been displayed? In this case this memory must be released next time you open the next pictures. Therefore (theoretically) just another 250-300 Mb would be blocked and used memory should not grow up after each shot. May be there is some way when picture has not be disposed? Behavior we can see on my laptop more similar to the situation when finalizer works incorrect and blocks GC for sometime. When deadlock has been broke up GC collect garbage. But its just a guessing... 

[admin]

Can you try the same scenario on a different computer, I want to see if you get the same behavior.  With and without the background server enabled.

Thank you

[Alexey Popov]

1 hour ago, admin said:

Can you try the same scenario on a different computer, I want to see if you get the same behavior.  With and without the background server enabled.

Thank you

Could you please explain, what do you expect from thus test? What does it give to you?

[admin]

It gives me more data points.

I want to know if you get the same out-of-memory error on another computer using the same steps you are currently using.

I don't expect anything, I want as many data points as possible.

[Alexey Popov]

Hmm.. Sorry, but I don`t like idea to spend my time for pointless occupation. What if I try same scenario and sing a song in the same time? I expect nothing but it gives you much more data point! What do you think about it? :))) The problem of the many data is that you need to explain it. Have you heard about scientific approach? Hypothesis -> model -> calculation -> observation -> O-C (observation - calculation) -> analysis  -> interpretation. System approach? 

Ok. Lets think a bit. The problem can be caused by internal or external problem. 

1. Internal.

1.1 Can be caused by late Dispose(). You made changes, give me a version, I`ll make test. 

1.2 Can be caused by problems with Finalize(). Do you use Finalize()?

1.3 Problem was introduced in some commit. Its possible that old versions do not have such problems. When you got first issue about this problem? Probably we should try to test old enough version?

1.4 Size depends on the pictures, its calculates from metadata. May be this behavior is typical for some cameras or formats? Did you ask other sufferer about cameras and photos?  What if I give you my pictures and you can try same scenario? 

External

2.1 Some problems in GC. First I would look in the web for the similar cases.  Probably we should to try this scenario on the another build of the .Net? So I need computer with another .Net. By the way, which .Net framework do you use? 4.5?

2.2 Some problems in GC reproduced on the specific PC architecture? x32 or x64? Another version of OS? What else? How many different computers I need for such test? Seems its impossible. But what if collect this statistics form other guys faced with this problem? Do you have this information? 

2.3 May be this is not a bug in GC but the feature? There are many articles about GC performance and some very interesting info inside (first link especially). May be its better to make the artificial test based on this knowledge? 

https://msdn.microsoft.com/en-us/library/ms973837.aspx

https://msdn.microsoft.com/en-us/library/ee851764(v=vs.110).aspx

 

I have old laptop with version 3.1.4 installed (currently I use 3.1.9) and OS Win 10 x64. I`ll try to reproduce problem on this laptop is possible or not. Its useful for me too. 

[astroman133]

Alexey,

If the problem is internal, why aren't more BYE/BYN users reporting the same symptoms as you? To me this doesn't seem likely.

Not to put words in his mouth, I think that Guylain's suggestion only seeks to convince you that the problem is external and related to your PC. If you are not able to re-create the same issues on a different box then you are in a good position to suggest which conditions are likely to be the culprit and which are not.

[Alexey Popov]

14 minutes ago, astroman133 said:

Alexey,

If the problem is internal, why aren't more BYE/BYN users reporting the same symptoms as you? To me this doesn't seem likely.

Not to put words in his mouth, I think that Guylain's suggestion only seeks to convince you that the problem is external and related to your PC. If you are not able to re-create the same issues on a different box then you are in a good position to suggest which conditions are likely to be the culprit and which are not.

That`s quite simple: because in some circumstance it`s happens more often while in another - more rarely. And this circumstance can be either internal (application settings, user behavior) or external (physical memory load, GC features or bad, etc). Probably, many people was faced with problem, but it happens very rare and not in a critical way (e.d. bug #1, clicks on thumbnail does not display picture).

[astroman133]

I don't disagree with you, but you are the best person to attempt to re-create your issues in a different environment. If you can do that then it will help to narrow down what is causing your issue.

[Alexey Popov]

Ok... Who is the best? I`m the best!  Recently I`ve got very interesting information! The report is coming

[admin]

42 minutes ago, Alexey Popov said:

Ok... Who is the best? I`m the best!  Recently I`ve got very interesting information! The report is coming

That is where you are wrong, I'm the best

Oh boy, 2 alpha males in the room, what can go wrong?

 

[Alexey Popov]

I made same test on my old laptop. As I wrote, BYE 3.1.4 is still installed on it. And its Win10 x64 with old weak i7 and 4 Gb RAM. It 3-4 times slower then my normal PC. I took the same files from session on 24.04.2017 and repeat:

0. I checked settings, in versiom 3.1.4 there is no setting about background worker. 

CASE A-1

3.  started with preview shooting first. The behavior was similar then last days, but the entire process itself was slower and it was not possible to reach really high level of memory usage. On ~500-700 Mb GC collected garbage. I made 24 shots without any problem.

1. Then I droped 101 pictures from last session into BYE and started to look on the mem usage in task manager. And the result was the same: the process itself was a few times more slower, I waited I think more then 10 minutes. The memory usage grew slowly up to 500-700 Mb and was reduced. There was no error in the log. 

2. After that I began clicking on the thumbnails - even better, not more then 500 Mb and no problem. The log is clear! 

CASE B-1

Ok... After that I installed 3.1.9 and repeat scenario with default settings (background worker switched off). And.. it was much worse then on the new laptop!!! 

1. I droped 101 pictures and less then 20 was loaded. In the logs - a lot of errors including out of memory. 

2. Then I started clicking on thumbnails - it was broken completely very fast.

3. Close and start application, preview shooting - 8 shots and game over. 

CASE C-1

After that I switched on background worker. 

1. Droped 101 picture. 101 picture loaded, no out of memory errors. 

2. Thumbnail function was broken in a few clicks. Preview does not work if mem usage higher then 800 Mb. And its very easy to get continues fail. 

3. Preview shooting. Restart and... SIX shots and game over. 

 

After that I uninstall 3.1.9 from my new laptop and install 3.1.4

CASE C-2

1. Dropped 101 picture. 101 picture loaded, NO ERROR! Memory usage not more then 700 Mb!

2. Thumbnails bar clicking. Usage memory grows, I got out of memory errors, but only single and at the level of mem usage higher the 1.2 Gb! In the moment of out of memory GC collected garbage, memory usage fall down  and next click opens next pictures. I was unable to get situation as days before when memory usage freeze on the high level and nothing works. 

3. Preview shots. Manually it was ok. I made ~20 shot without problem. Two times mem usages reached 1.2 Gb and was decreased with no error.

And.. After that I decided to use Loop function. The mem usage come over 1.2 Gb and I got out of memory error :(( 

No, I`m not the best

 

But the result is interesting in any case. Version 3.1.4 much more stable. You did something in between 3.1.4 and 3.1.9 what made it worse.

What else? 3.1.9 take memory much faster. I think each display operation took 2 time more memory, then in 3.1.4. 

And result are the same on the two very different laptops with very different OS. 

 

[admin]

3.1.4 uses the background server and you can not turn it off.

3.1.9 by default it is off and when you turn it on it is the same as 3.1.4 in that respect.

Your test is not comparing the same thing because of this but I appreciate the data points.  You need to enable the background server in 3.1.9 for this to be useful.

Okay, time for me to walk away and rethink this and trace the the memory usage.  

We have already establish there is something wrong with the thumbnail, I will look at this.

I'm not convince there is something with image capture though but I'm not convinced there is not either.

I'll go dark for a short while on this topic so I can dig into it some more.

Regards, 

[Alexey Popov]

My test IS comparing the same thing. You can skip results with switched of background worker and its obvious: 3.1.4 works much more stable.  Compare cases A-1 and C-1 and yesterday result and C-2.

 

[Alexey Popov]

Another conclusion from this test is the following: you will have more and more request about this problem in the course of time while people install new version. 

[admin]

I have found something with the thumbnail control itself.  I'm fixing it now.  This should prevent out-of-memory errors when clicking thumbnail and when dragging images to load.  I jutst dragged 500 images and all loaded with no errors and memory usage was hovering around 450 MB or less at all times. 

I did not find any memory issues with images taken from imaging sequences; all images are properly disposed of and memory is recycled when the GC passes to reclaim dead memory... albeit it could be running a bit more often.  Calling a GC.Collect() after each image displayed does help to bring down the memory uses down on a regular basis.  However, it is well known that this is not good development practice but in the case it does help by releasing memory sooner so I'll leave it in there and should be in 3.1.10.

I'll run more tests before drawing any more conclusion.

Thank you for your tenacity and persistence in reporting this.

Regards,

[admin]

On 4/28/2017 at 5:39 PM, Alexey Popov said:

My test IS comparing the same thing. You can skip results with switched of background worker and its obvious: 3.1.4 works much more stable.  Compare cases A-1 and C-1 and yesterday result and C-2.

 

Yes, you are correct.

[admin]

On 4/29/2017 at 5:28 PM, admin said:

I have found something with the thumbnail control itself.  I'm fixing it now.  This should prevent out-of-memory errors when clicking thumbnail and when dragging images to load.  I jutst dragged 500 images and all loaded with no errors and memory usage was hovering around 450 MB or less at all times. 

I did not find any memory issues with images taken from imaging sequences; all images are properly disposed of and memory is recycled when the GC passes to reclaim dead memory... albeit it could be running a bit more often.  Calling a GC.Collect() after each image displayed does help to bring down the memory uses down on a regular basis.  However, it is well known that this is not good development practice but in the case it does help by releasing memory sooner so I'll leave it in there and should be in 3.1.10.

I'll run more tests before drawing any more conclusion.

Thank you for your tenacity and persistence in reporting this.

Regards,

 

HI Alexey,

Please download 3.1.10, you should see significant improvements.

Regards,

[Alexey Popov]

10 hours ago, admin said:

 

HI Alexey,

Please download 3.1.10, you should see significant improvements.

Regards,

Hi Guylain, the test is done. The same scenario with extension at the end. Version 3.1.10, background worker switched on. 

1. 101 Pectures dropped, 101 pictures loaded. No error in the log. Mean mem usage grew slowly up to 600 Mb in maximum and fall down to 328 Mb after end. OK!
2. Clicking on thumbnail. Couple of minutes intensive clicking. Mem usegas did not exceed 500 Mb and mem released very quickly after next picture displaying.I see no problem. OK!
3. Preview shooting. Series of 30 shorts with 1 sec shutter. No lost images, no errors in log, maximum mem usage around 500 Mb. OK!
4. Image rotating. Mem usage grows fast and reach 1.2 Gb after ~25 clicks where we have game over. 
Video: https://www.dropbox.com/s/zcc2jo5sr64c6li/BYE_2017_05_01_rotate.avi?dl=0
LOg:
2017-05-01 11:28:42,347 [Main] ERROR - Out of memory.
2017-05-01 11:28:42,347 [Main] ERROR -    at System.Drawing.Graphics.CheckErrorStatus(Int32 status)
   at System.Drawing.Graphics.DrawImage(Image image, Int32 x, Int32 y, Int32 width, Int32 height)
   at System.Drawing.Bitmap..ctor(Image original, Int32 width, Int32 height)
   at System.Drawing.Bitmap..ctor(Image original)
   at BinaryRivers.Controls.ABase.PictureBoxPlus.set_Image(Image value)
   at BinaryRivers.BackyardEOS.Modes.CaptureMode.iconPlus1_MouseClick(Object sender, MouseEventArgs e)
2017-05-01 11:28:42,733 [Main] DEBUG - IconPlus_MouseClick(iconRotate180 = '')
2017-05-01 11:28:42,740 [Main] ERROR - A generic error occurred in GDI+.
2017-05-01 11:28:42,740 [Main] ERROR -    at System.Drawing.Image.RotateFlip(RotateFlipType rotateFlipType)
   at BinaryRivers.BackyardEOS.Modes.CaptureMode.iconPlus1_MouseClick(Object sender, MouseEventArgs e)
2017-05-01 11:28:43,257 [Main] DEBUG - IconPlus_MouseClick(iconRotate180 = '')
2017-05-01 11:28:43,257 [Main] ERROR - A generic error occurred in GDI+.
2017-05-01 11:28:43,257 [Main] ERROR -    at System.Drawing.Image.RotateFlip(RotateFlipType rotateFlipType)
   at BinaryRivers.BackyardEOS.Modes.CaptureMode.iconPlus1_MouseClick(Object sender, MouseEventArgs e)
2017-05-01 11:28:43,696 [Main] DEBUG - IconPlus_MouseClick(iconRotate180 = '')
2017-05-01 11:28:43,696 [Main] ERROR - A generic error occurred in GDI+.
2017-05-01 11:28:43,696 [Main] ERROR -    at System.Drawing.Image.RotateFlip(RotateFlipType rotateFlipType)
   at BinaryRivers.BackyardEOS.Modes.CaptureMode.iconPlus1_MouseClick(Object sender, MouseEventArgs e)
2017-05-01 11:28:44,159 [Main] DEBUG - IconPlus_MouseClick(iconRotate180 = '')
2017-05-01 11:28:44,160 [Main] ERROR - A generic error occurred in GDI+.
2017-05-01 11:28:44,160 [Main] ERROR -    at System.Drawing.Image.RotateFlip(RotateFlipType rotateFlipType)
   at BinaryRivers.BackyardEOS.Modes.CaptureMode.iconPlus1_MouseClick(Object sender, MouseEventArgs e)

It` hard for me to imagine situation when somebody needs to rotate image 25 times running, but it means you still have places in code where memory does not release fast. And you have the same problems in other functions (tested): 

- switch on/off grid on pictures

- switch on/off opacity

May be somewhere else. 

So, as a conclusion: version 3.1.10 is much more stable really, but still have a few mem usage problems. I think it could be considered as non-critical. Could be, because as Edsger Dijkstra sais "Program testing can be used to show the presence of bugs, but never to show their absence!" - highly possible I`ve found not all mem usage problems. But I think you can find similar problems directly in code because you know general template now. 

 

 

[Alexey Popov]

According to other problems: 

#3 I`ll test again later with different versions. This problem appears not long ago.

#4 Ok, I`ll test it with administrative rights. If it works - no problem. 

Whats about #5 (countdown and mirror lock)? Will be fixed? 

[admin]

For #4 you could re-install is a separate folder and the issue should be resolved.

Nothing done for #5 yet.

[Alexey Popov]

10 minutes ago, admin said:

For #4 you could re-install is a separate folder and the issue should be resolved.

Nothing done for #5 yet.

#4 Hm.. What do you mean under separate folder? Folder outside Program Files? 

#5 - I see, but should we expect bug fixing, or its a kind of "Won't Fix"?