DAGView

Discussion about the development of the Assembly workbench.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Fat-Zer
Posts: 176
Joined: Thu Oct 30, 2014 10:38 pm

Re: DAGView

Post by Fat-Zer »

Fat-Zer wrote:For me there is a failed assertion when scrolling back history:
ok, seems it's not related to history, I received the same crash then deleted a lot of objects, but not every time... seems there is some race condition...
tanderson69 wrote:Ok. Keep in mind that you can turn the dagview completely off in the parameters. That way the assert won't be bugging you while you investigate the problem.
I know, but I'm debugging migration and the DAG view is very helpul when I got strange results...
jmaustpc
Veteran
Posts: 11207
Joined: Tue Jul 26, 2011 6:28 am
Location: Australia

Re: DAGView

Post by jmaustpc »

Hi all
A note about those icons, I noticed a while back that those C++/default icons show up first and then are replaced by the Draft WB/Python defined icons. You would normally never notice or be able to see this because it would happen so fast.

I could see this because FreeCAD was running so slowly for me at the time, the first icons would appear then almost instantly be replaced by the Draft WB icon. I was experimenting with different icons for some Draft WB objects, so I was fiddling around with the code trying to understand what part of the code defined those icons etc., I don't know now exactly why FreeCAD was running so slow but possibly due to some combination of it was a Debug compile, possibly running in GDB and I could have had both cores at maximum compiling another FreeCAD while operating another FreeCAD.

Anyway I just thought I would post this, perhaps unusual, observation in case it helps at all.

Jim
User avatar
tanderson69
Veteran
Posts: 1626
Joined: Thu Feb 18, 2010 1:07 am

Re: DAGView

Post by tanderson69 »

Fat-Zer wrote:
Fat-Zer wrote:For me there is a failed assertion when scrolling back history:
ok, seems it's not related to history, I received the same crash then deleted a lot of objects, but not every time... seems there is some race condition...
It looks like we have reached a state where the App::DocumentObject has been deleted but the ViewProviderDocumentObject is good, or at least the ViewProviderDocumentObject delete signal hasn't made it to the dagview model. Boost signals are synchronous so I don't see how it could be a race condition... unless maybe something with the python layer? I can't get it to crash here, but I am on another branch at the moment. What branch are you using?
User avatar
yorik
Founder
Posts: 13640
Joined: Tue Feb 17, 2009 9:16 pm
Location: Brussels
Contact:

Re: DAGView

Post by yorik »

jmaustpc wrote:A note about those icons, I noticed a while back that those C++/default icons show up first and then are replaced by the Draft WB/Python defined icons. You would normally never notice or be able to see this because it would happen so fast.
Probably this is because the feature gets created first, then its python object is set, which overrides the default icon... In the small timeframe between the two, some GUI update must have happened. But even so, the view provider should return the correct icon after the python object has been set...
User avatar
tanderson69
Veteran
Posts: 1626
Joined: Thu Feb 18, 2010 1:07 am

Re: DAGView

Post by tanderson69 »

yorik wrote:Probably this is because the feature gets created first, then its python object is set, which overrides the default icon... In the small timeframe between the two, some GUI update must have happened. But even so, the view provider should return the correct icon after the python object has been set...
Allright! this is making sense now. The treeview has to combine the status icon with the feature icon frequently, so it (the treeview) gets the icon from the viewprovider every time it updates the status. The dagview has it's own status column so it doesn't need to combine and it just stores the feature icon upon feature creation. As yorik points out this is happening before the python object overrides the icon. Now I have a lead. Thanks.
jmaustpc
Veteran
Posts: 11207
Joined: Tue Jul 26, 2011 6:28 am
Location: Australia

Re: DAGView

Post by jmaustpc »

tanderson69 wrote:
yorik wrote:Probably this is because the feature gets created first, then its python object is set, which overrides the default icon... In the small timeframe between the two, some GUI update must have happened. But even so, the view provider should return the correct icon after the python object has been set...
Allright! this is making sense now. The treeview has to combine the status icon with the feature icon frequently, so it (the treeview) gets the icon from the viewprovider every time it updates the status. The dagview has it's own status column so it doesn't need to combine and it just stores the feature icon upon feature creation. As yorik points out this is happening before the python object overrides the icon. Now I have a lead. Thanks.
Hi Thomas
Now I wish I had the courage to post about that earlier, since you guys are talking over my head, I thought I was probably wasting your time. :)

Jim
User avatar
tanderson69
Veteran
Posts: 1626
Joined: Thu Feb 18, 2010 1:07 am

Re: DAGView

Post by tanderson69 »

jmaustpc wrote:Hi Thomas
Now I wish I had the courage to post about that earlier, since you guys are talking over my head, I thought I was probably wasting your time. :)
Every post is just noise, until its not. ;)
User avatar
yorik
Founder
Posts: 13640
Joined: Tue Feb 17, 2009 9:16 pm
Location: Brussels
Contact:

Re: DAGView

Post by yorik »

tanderson69 wrote:Every post is just noise, until its not. ;)
This is a cool motto for this forum :)
Fat-Zer
Posts: 176
Joined: Thu Oct 30, 2014 10:38 pm

Re: DAGView

Post by Fat-Zer »

tanderson69 wrote:It looks like we have reached a state where the App::DocumentObject has been deleted but the ViewProviderDocumentObject is good, or at least the ViewProviderDocumentObject delete signal hasn't made it to the dagview model. Boost signals are synchronous so I don't see how it could be a race condition... unless maybe something with the python layer? I can't get it to crash here, but I am on another branch at the moment. What branch are you using?
The branch is:
https://github.com/Fat-Zer/FreeCAD_sf_m ... aseFeature
Announced here: viewtopic.php?f=20&t=11917&p=96860#p96860
Be aware, this will call a big rebuild...

Steps to reproduce:
1. Open soft-drink-can.fcstd from yorikvanhavre's FreeCAD-library: https://github.com/yorikvanhavre/FreeCA ... -can.fcstd
2. Part Disign->Migrate
3. delete can-src
User avatar
tanderson69
Veteran
Posts: 1626
Joined: Thu Feb 18, 2010 1:07 am

Re: DAGView

Post by tanderson69 »

Fat-Zer wrote:Steps to reproduce:
1. Open soft-drink-can.fcstd from yorikvanhavre's FreeCAD-library: https://github.com/yorikvanhavre/FreeCA ... -can.fcstd
2. Part Disign->Migrate
3. delete can-src
Great! that makes it a lot easier when you can reproduce!



I noticed a std::string exception was being thrown. I completely turned off the DAGView and made sure the exception was still there. It was. I have attached the back trace. Clip from attached back trace:

Code: Select all

#3  0x00007ffff480b526 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x00007ffff680a312 in App::Document::remObject (this=0x192daa0, sName=0x0, forceIfUndeletable=false) at /home/tanderson/Programming/freeCad/free-cad-git/src/App/Document.cpp:1620
#5  0x00007ffff6852eed in App::DocumentObjectGroup::removeObjectFromDocument (this=0x1fd4df0, obj=0x2e61b40)
    at /home/tanderson/Programming/freeCad/free-cad-git/src/App/DocumentObjectGroup.cpp:95
I believe this is caused by the fact that after your migration routine the group objects contain multiple links to the same feature. So basically it is trying to delete a feature that has already been deleted. This causes an exception to be thrown. I haven't traced where the exception lands, but I am guessing the deletion operation is quit half way through.

pre-migration:
PreMigration.png
PreMigration.png (141.18 KiB) Viewed 2448 times

post-migration:
PostMigration.png
PostMigration.png (280.94 KiB) Viewed 2448 times
You can see in the post migration that the group features contain multiple links to the same feature. I don't think that is an acceptable state for group features. fix that, and I think the exception and the dagview assert will go away.
Attachments
stringException.txt
(7.92 KiB) Downloaded 77 times
Post Reply