Re: [Fwbuilder-discussion] Odd GUI behavior

[Juan P. V. <jp...@gm...>]

Hi Vadim, I always export the library as read-write. I'll send you the data
file in a few minutes.

Regards,
JP.-

On Fri, Feb 12, 2010 at 5:48 PM, Vadim Kurland <va...@vk...>wrote:

>
>
> On Fri, Feb 12, 2010 at 12:30 PM, Juan Pablo Villa <jp...@gm...>wrote:
>
>> Hi all, I'm testing the latest builds (I'm on build 2506) and I came
>> across two major problems. Right now I'm running a considerable size object
>> file (300kb uncompressed), that's been rolling over several nightly builds
>> (at least 3.1 b2311).
>>
>> One of them, involves pretty much any edit operation of an object. The GUI
>> tends to segfault (tested on ubuntu hardy amd64, ubuntu jaunty amd64 and
>> win32). I have found a workaround to that... exporting the user library to a
>> fwl file, then open it again as a file, and save the resulting as a fwb
>> file. If you do that, the next edit operation works ok. I have been unable
>> to reproduce this problem while working on other small object files.
>>
>>
> one thing that happens when you export objects to a library file, is that
> you can set the library read-only or read-write. There is a checkbox at the
> bottom of the dialog where you choose which library to export. How did you
> set it  ?
>
> In any case, I need more information on this crash to fix it. Can you send
> your data file to me ? If not, please try to find the core file produced
> when the program crashes and get debugger output from it.  The "support"
> page on our web site explains how to get debug trace if you have the core
> file:
>
> http://www.fwbuilder.org/contact.html
>
> On some systems generation of the core files may be disabled. Run command
> "ulimit -a" on the shell prompt and see what does it say for "core file
> zie". If it says "0", then it is disabled. Command "ulimit -c unlimited"
> sets it to unlimited and enables it. You should then start fwbuilder GUI in
> the same shell session to make it produce core file when it crashes again.
>
>
>
>
>> The other issue involves any operation on the rulesets (Policy, NAT and
>> Routing). Any modification you make, the message "Searching for firewalls
>> affected by the change." appears, and the CPU goes to 100% for a while. The
>> message dissapears shortly, but the CPU usage and the GUI unresponsiveness
>> remains (this on ubuntu hardy amd64, which is a VM). This happens randomly,
>> because on some occasions the GUI is pretty slick on a change, and pretty
>> much of the time not. I tested this on a dedicated ESX server, and I can
>> tell that it is not a VM resources issue.
>>
>>
> the GUI has to scan all objects to find firewalls affected by the change.
> Since your data file is large, it has to do a lot of work. I may be able to
> find a way to speed it up but I need your data file to test with.
>
>
>
>
>> On Windows and ubuntu jaunty under physical hardware, there is a moment
>> where the GUI becomes unresponsive, but it's much smaller and not an issue.
>>
>> Sadly, I don't have amd64 iron left to test how hardy performs under
>> physical hardware.
>>
>>
> I dont think this is hardware-related problem. Unfortunately it seems to be
> consistent with expected behavior on a very large data file. I should look
> at the ways to speed it up.
>
> --vk
>
>
>
>