Re: Zenmap dies on MacOS X 10.5.1

[Daniel Johnson <daniel () daniel-johnson org>]

On Dec 4, 2007, at 1:28 PM, David Fifield wrote:

> On Tue, Dec 04, 2007 at 12:50:29PM -0500, Daniel Johnson wrote:
> > I'm also having zenmap crashing on 10.5.1, but in a different way. I
> > maintain the nmap package for Fink and have an experimental 4.23RC3
> > package that works, but zenmap always crashes after completing a  
> > scan.
> > This is the error:
> >
> > CRASH REPORTED:
> >    SYS.PLATFORM: darwin
> >    OS.NAME: posix
> >    Zenmap Version: 4.23RC3
> >
> > --------------------------------------------------------------------------------
> > STDOUT
> >
> >
> >
> > --------------------------------------------------------------------------------
> > STDERR
> > CRITICAL - 2007-12-04 11:54:57,083 - execute_command nmap -d -T
> > Aggressive -A -v 192.168.1.1
> >  File "/sw/lib/python2.5/site-packages/umitGUI/ScanNotebook.py",
> > line 916, in update_host_info
> >    self.switch_host_details(host_objs[0]['page'])
> >  File "/sw/lib/python2.5/site-packages/umitGUI/ScanNotebook.py",
> > line 988, in switch_host_details
> >    elif len(page) == 1:
> >
> >
> > HOOK:
> > Type: <type 'exceptions.TypeError'>
> > Value: object of type 'ScanHostDetailsPage' has no len()
> >
> > It seems that 'page' is missing the len() function? I'm not very
> > familiar with python.
>
> Hmm, I don't know. What version of PyGTK are you using?
> ScanHostDetailsPage is a subclass of gtk.Expanderm, which for me has a
> length (len(page) -> 2 in this case). len() is implemented as a method
> called __len__, which in PyGTK 2.10.4 is inherited by gtk.Expander  
> from
> gtk.Container.
>
> But I think the code is mistaken anyway. It looks more like
> switch_host_details is able to take either a single page or a list of
> pages. The code that says "if type(page) == type([])" is testing if  
> page
> is a list. I think that
>
>         elif len(page) == 1:
>
> is trying to see if page is a list containing more than one page,  
> but it
> also will be true if page is a gtk.Expander containing a single  
> element.
> Can you try the attached patch?

With this patch, zenmap works. Thanks! I think my problem was that my  
PyGTK is old: 2.6.6. Fink is in the process of upgrading to the latest  
GTK, but because of the dependency on cairo it has been necessary to  
update hundreds of packages simultaneously with new dependencies and  
it's taking a lot of time. :/

> > I have also have a building issue that I've worked around, but  
> > perhaps
> > I'm missing something obvious. Fink installs packages into a  
> > temporary
> > root directory first which is then packed up in a .deb by dpkg.
> > The .deb is then installed in the real root location by dpkg. The
> > problem is that setup.py always encodes the temporary root path in  
> > the
> > compiled files even if I use --root and --prefix and therefore zenmap
> > looks for its files in the wrong place. I've been patching setup.py
> > during building to change the paths like this:
> >
> > perl -pi -e 's#result = result\[0\]#result = re.sub("%i", "%p",
> > result[0])#' zenmap/setup.py
> >
> > where %i is replaced with the temporary root and %p with the real  
> > root
> > prefix; Fink automatically replaces them with the correct values. Now
> > again I'm no python expert, so I might be missing something. My way
> > works, but is hardly elegant. :)
>
> Really, even with 4.23RC3? I changed setup.py to properly handle -- 
> root
> and --prefix in r6133 on November 4. I needed to do that in order to
> make a Zenmap RPM--the RPM build process does the same thing,  
> installing
> in a temporary root and then packaging for a real root. That
> "result = result[0]" code isn't in the current revision of setup.py.

Um, I'm a moron. That patch was necessary up to RC2, but I missed that  
it was fixed in RC3. Nevermind. :)

One more thing: the --no-cpp-precomp flag set in configure.ac has been  
a no-op on Mac OS X since the gcc 3.3 compiler on 10.2. It's useless  
on 10.2-gcc3.3 and later and is likely to disappear altogether at some  
point.

Daniel

Attachment: smime.p7s
Description:

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org