kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #10633
Re: pcbnew hang
On 06/17/2013 11:34 AM, Wayne Stambaugh wrote:
> On 6/17/2013 6:19 AM, Chris Morgan wrote:
>> It looks like I won't be able to test the fix here. The
>> flag, /wxDIR_NO_FOLLOW/, appears to have been added in wxWidgets 2.9.5
>> according to the documentation.
>>
>> http://docs.wxwidgets.org/trunk/dir_8h.html#aa45988fae9ce0d0c4f8312a6cf026232a25c09a8059a40281ca2d7919d84b4941
>>
>> But on Kubuntu 13.04 wxWidgets is version 2.8.12.....
>>
>> Chris
>
> Even if you had wxWidgets 2.9.5 installed (which isn't even released
> yet), adding wxDIR_NO_FOLLOW still wouldn't work. I just looked at the
> the latest source code of dircmn.cpp in the wxWidgets repo and the
> wxDirTraverserSimple is still the same as 2.8.12. It looks like the
> wxWidgets folks only added the new flag to <wx/dir.h> and haven't gotten
> around to implementing anything with it yet. The latest commit message
> for dircmn.cpp is:
>
> "Change the way directory iteration flags are constructed.
>
> Instead of explicitly constructing the flags from the flags that should
> be included, construct them by excluding the flags that shouldn't be
> used. This makes the code more stable in the sense that it will continue
> to work when new flags, such as the upcoming wxDIR_NO_FOLLOW, are added.
>
> See #14542."
>
> It looks like they already know about this problem and there is a bug
> report filed against it. You will have to remove your broken symlinks
> to resolve your issue for now. I looks like I have another task on my
> list to find a solution in order to get the footprint library table
> implemented... Sigh!!!
>
> Wayne
Solutions, none of which are mutually exclusive:
Solution A:
===========
$ export KISYSMODS=/usr/local/share/modules
C:>set KISYSMODS=C:/kicad/share/modules
This can be done as part of the desktop icons or program launchers, or other more
permanent place.
On linux a person could do this to capture a temporary setting of the environment variable
just before launching the application called kicad:
KISYSMODS=/usr/local/share/modules kicad
this text is actually a reasonable choice for the desktop shortcut.
Solution B:
===========
// Path list for KiCad data files
static wxString s_KicadDataPathList[] = {
#ifdef __WINDOWS__
wxT( "c:/kicad/share/" ),
wxT( "d:/kicad/share/" ),
wxT( "c:/kicad/" ),
wxT( "d:/kicad/" ),
wxT( "c:/Program Files/kicad/share/" ),
wxT( "d:/Program Files/kicad/share/" ),
wxT( "c:/Program Files/kicad/" ),
wxT( "d:/Program Files/kicad/" ),
#else
wxT( "/usr/share/kicad/" ),
wxT( "/usr/local/share/kicad/" ),
wxT( "/usr/local/kicad/share/" ), // default data path for "universal
// tarballs" and build for a server
// (new)
wxT( "/usr/local/kicad/" ), // default data path for "universal
// tarballs" and build for a server
// (old)
#endif
wxT( "end_list" ) // End of list symbol, do not change
};
Scrap the above in gestfich.cpp.
Go instead to a CMake "datapath" variable, something like CMAKE_INSTALL_PREFIX, but data
specific. (Must we always assume that application code and application data are tied
together, please no.) And generate the correct path from from a cmakedefine in
config.h.in. Then simply hard code that path in your code now, rather than guesstimating
it.
On the unrelated subject of CMAKE_INSTALL_PREFIX, what we have now is the possibility that
someone sets CMAKE_INSTALL_PREFIX into a wild blue yonder, and that the wild blue yonder
dir is not in the list above, not even in "end_list", although it seems everyone should
have an "end_list", just for good luck. Also, the poor guy who installs on drive G: in
windows is hosed, of course that is another way of saying wild blue yonder.
The installation system in CMake on Linux is actually at the top of my work queue now.
Promise. I am one of those guys that does not benefit from linux packages, so the
install() statements in CMakeLists.txt have greater ramifications for me than most. It
would be nice to have the notion of a datapath and a codepath. I read about that
somewhere. CMAKE_INSTALL_PREFIX can only serve one of those needs.
I have two excellent sets of patches to look over, and this should happen in the next 10
days. I can give this option B some more thought at that time also, at least the
cmakedefine. Your choice to use it is something for you to think about.
Dick
>
>>
>>
>>
>>
>>
>>
>>
>> On Sun, Jun 16, 2013 at 12:46 PM, Chris Morgan <chmorgan@xxxxxxxxx
>> <mailto:chmorgan@xxxxxxxxx>> wrote:
>>
>> Oh that flag is allowed for the getallfiles call. I would have tried
>> that if I had noticed that. Ill give it a shot tonight but I bet that
>> will fix it. Whether it is the right thing to do is another thing.
>>
>> Chris
>>
>>
>>
>> On Jun 16, 2013, at 11:25 AM, Wayne Stambaugh
>> <stambaughw@xxxxxxxxxxx <mailto:stambaughw@xxxxxxxxxxx>> wrote:
>>
>> > On 6/15/2013 8:12 PM, Chris Morgan wrote:
>> >> Dick turned out to be correct, that was some good insight there.
>> >>
>> >> Attached strace to the process and sure enough it is traversing a
>> >> directory that has symlinks, several of which appear to be
>> pointing back
>> >> to the same directory. So, the process is making progress but
>> because of
>> >> the several symlink loops its taking a long long time to complete.
>> >>
>> >> It looks like if we used
>> >>
>> http://docs.wxwidgets.org/trunk/dir_8h.html#aa45988fae9ce0d0c4f8312a6cf026232a25c09a8059a40281ca2d7919d84b4941
>> instead
>> >> of wxDir then we would be able to disable symlink traversal.
>> >>
>> >> Chris
>> >>
>> >>
>> >>
>> >>
>> >> On Sat, Jun 15, 2013 at 5:46 PM, Chris Morgan <chmorgan@xxxxxxxxx
>> <mailto:chmorgan@xxxxxxxxx>
>> >> <mailto:chmorgan@xxxxxxxxx <mailto:chmorgan@xxxxxxxxx>>> wrote:
>> >>
>> >> Ok. Ill see what I can come up with. Good idea on the recursive
>> >> symlink. Surprised wx wouldn't handle that situation.
>> >>
>> >> Ill try to figure it out this evening.
>> >>
>> >> Chris
>> >
>> > Chris,
>> >
>> > When you get time, please try changing:
>> >
>> > unsigned cnt = wxDir::GetAllFiles( GetLibraryPathList()[i], &tmp,
>> wxT( "*.mod" ) );
>> >
>> > to:
>> >
>> > unsigned cnt = wxDir::GetAllFiles( GetLibraryPathList()[i], &tmp,
>> wxT( "*.mod" ), wxDIR_DEFAULT | wxDIR_NO_FOLLOW );
>> >
>> > and see if that resolves the problem. It's seems odd to me that
>> it works correctly when Pcbnew is run directly from the command line
>> but fails when Pcbnew is launched from KiCad. Are you using a debug
>> build? It may be possible that wxWidgets is trying log something to
>> stdout and that is what is actually causing it hang.
>> >
>> > I wont be able to look at this until sometime tonight or tomorrow.
>> I plan on enjoying the rest of Fathers Day with the family. Good
>> catch and thanks for the help.
>> >
>> > Happy Father's Day to all of you fathers out there.
>> >
>> > Wayne
>> >
>> >
>> >>
>> >>
>> >>
>> >> On Jun 15, 2013, at 5:31 PM, Dick Hollenbeck <dick@xxxxxxxxxxx
>> <mailto:dick@xxxxxxxxxxx>
>> >> <mailto:dick@xxxxxxxxxxx <mailto:dick@xxxxxxxxxxx>>> wrote:
>> >>
>> >> > No idea. This is new code.
>> >> >
>> >> > KISYSMOD env var is not used yet, so one option is to
>> comment out
>> >> the entire block from
>> >> > 194 to 213.
>> >> >
>> >> > But I think Wayne would appreciate getting help nailing the
>> >> problem. You can try and log
>> >> > the execution with fprintf(). Using printf() likely won't
>> work,
>> >> since the output as a
>> >> > child process is directed into parent process "kicad".
>> >> >
>> >> > So fprintf() is a good quick test. Write GetCount() at the
>> top,
>> >> then each iteration and
>> >> > the path that you are going into. I think will be informative.
>> >> gdb is probably not up to
>> >> > that task.
>> >> >
>> >> > Then simply do bzr revert pcbnew/pcbnew.cpp when you are done.
>> >> >
>> >> > You might have a circular set of symlinks, who knows. the log
>> >> file you create will tell.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > Mailing list: https://launchpad.net/~kicad-developers
>> >> > Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>> >> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx
>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
>> >> > Unsubscribe : https://launchpad.net/~kicad-developers
>> >> > More help : https://help.launchpad.net/ListHelp
>> >>
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> Mailing list: https://launchpad.net/~kicad-developers
>> >> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>> >> Unsubscribe : https://launchpad.net/~kicad-developers
>> >> More help : https://help.launchpad.net/ListHelp
>> >
>> >
>> > _______________________________________________
>> > Mailing list: https://launchpad.net/~kicad-developers
>> > Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>> > Unsubscribe : https://launchpad.net/~kicad-developers
>> > More help : https://help.launchpad.net/ListHelp
>>
>>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
>
Follow ups
References