[Geany] Mac OSx Snow Leopard experience, 100% CPU load whenever build has been started !
Lex Trotman
elextr at xxxxx
Fri May 21 09:07:26 UTC 2010
On 21 May 2010 16:55, Andrei Vishneuski <vish at gravitysoft.org> wrote:
> On 05/21/2010 02:06 AM, Lex Trotman wrote:
>
>
>
> On 21 May 2010 02:49, Andrei Vishneuski <vish at gravitysoft.org> wrote:
>
>>
>> On 20 mei 2010, at 12:48, Lex Trotman wrote:
>>
>>
>>
>> On 20 May 2010 20:20, Andrei Vishneuski <vish at gravitysoft.org> wrote:
>>
>>>
>>> On 20 mei 2010, at 11:42, Lex Trotman wrote:
>>>
>>>
>>>
>>> On 20 May 2010 19:28, Andrei Vishneuski <vish at gravitysoft.org> wrote:
>>>
>>>>
>>>> On 19 mei 2010, at 22:34, Enrico Tröger wrote:
>>>>
>>>> > On Tue, 18 May 2010 21:40:03 +0200, Andrei wrote:
>>>> >
>>>> >> On 05/18/2010 01:31 PM, Andrei Vishneuski wrote:
>>>> >>>
>>>> >>>
>>>> >>> On 18 mei 2010, at 13:22, Lex Trotman wrote:
>>>> >>>
>>>> >>>>
>>>> >>>>
>>>> >>>> On 18 May 2010 20:37, Andrei Vishneuski <vish at gravitysoft.org
>>>> >>>> <mailto:vish at gravitysoft.org>> wrote:
>>>> >>>>
>>>> >>>> I am big fun of Geany and have used it in Windows and Linux as
>>>> >>>> my primary development editor.
>>>> >>>> The problem is usage of Geany under Mac OSx.
>>>> >>>> Basically under Mac osx you have three options:
>>>> >>>>
>>>> >>>> 1) Install port and install geany through the port. This is the
>>>> >>>> most simple way. Geany looks a little bit ugly but workable
>>>> >>>> and fast. 2) Deploy native Mac OSx GTK (see gtk-osx). More
>>>> >>>> complicated way to use Geany. Geany looks more integrated with Mac
>>>> >>>> OSx, but it is SLOW !
>>>> >>>> 3) Use virtual (Linux) machine. Not a graceful way but better
>>>> >>>> than nothing.
>>>> >>>>
>>>> >>>> I have tried all three options. And unfortunately only third
>>>> >>>> option is applicable.
>>>> >>>>
>>>> >>>> Options 1) and 2) has critical bug. If you try to build
>>>> >>>> something geany starts consuming 100% CPU time !
>>>> >>>> It seems there is something wrong with process output reading,
>>>> >>>> geany cannot correctly finalize it and stuck somewhere in
>>>> >>>> reading loop.
>>>> >>>>
>>>> >>>> Does anybody have the same experience and may be just by chance
>>>> >>>> has found a workaround ?
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> Which versions of Geany and Glib and GTK?
>>>> >>>>
>>>> >>> Geany 0.18.1
>>>> >>> 1) Mac OSx port GTK2 2.18.2
>>>> >>> 2) native gtk-osx GTK2 don't know exact version they are supporting
>>>> >>> (have to see my home PC to give you more information)
>>>> >>
>>>> >> I little bit more about gtk-osx version: geany 0.18.1 (built on May
>>>> >> 18 2010 with GTK 2.18.2, GLib 2.22.2)
>>>> >> Geany and gtk-osx has been compiled as i386 applications since 64bits
>>>> >> version of gtk-osx is no stable yet.
>>>> >>
>>>> >> PS: frankly speaking I think it is not GTK related bug, since I have
>>>> >
>>>> > It doesn't need to be a GTK/GLib bug but maybe we just use it wrong or
>>>> > it behaves differently on MacOSX or MacOSX behaves differently than
>>>> > Linux/Unix. I can't say what's wrong and I don't have access to a
>>>> > MacOSX system :(.
>>>>
>>>>
>>>> Could you give me a brief use case how the build feature works
>>>> (several general steps) and point the file
>>>> where I can find code responsible for it. May be I will try to take a
>>>> look at the
>>>> problem closer (cannot guarantee since I have not used C/C++ for ages
>>>> :)). As far as I can see practically everything works:
>>>> it executes appropriate tool for compilation, gets output from the tool,
>>>> parses output and makes parsed results visible in compile
>>>> window. But after that geany CPU load is 100%.
>>>>
>>>
>>> Oh, the load remains 100% forever after??? Do you get a success message
>>> in the status bar?
>>>
>>> Can you try the nightly build version but configure the "build" to run a
>>> shell script that just does a delay so you can check if the load starts
>>> before the end of the build or after completion.
>>>
>>>
>>>
>>>>
>>>> I have tried geany night build and geany 0.17. They have the same
>>>> problem.
>>>>
>>>>
>>> Ok, thanks, 0.17 lets out new build bits I added :-) but we've still got
>>> to fix the problem :-(
>>>
>>>
>>>> PS: Buy the way, several days ago VirtualBox 3.2 has been released. One
>>>> of the very interested
>>>> feature is support for Mac OSx. That means it is possible to install
>>>> original Mac OSx from
>>>> original oficial DVD. It could be a good way to test geany for this
>>>> platform.
>>>>
>>>
>>> If one has a DVD, doesn't a Mac come from a place with golden arches??
>>> Thats how much I know about them I'm afraid.
>>>
>>>
>>> The problem with Mac OSx is mac hardware uses more modern PC (EFI
>>> instead of BIOS) architecture and of course it is impossible
>>> just to take official Mac OSx DVD and install it on any PC even if the
>>> hardware has identical CPU/GPU/etc. And reverse: it is
>>> impossible to install Linux/Windows on mac hardware as is, without
>>> special boot loaders that emulates BIOS existence.
>>>
>>> There are several unofficial projects that modify (hack) original DVD
>>> (most of them add special boot loader which makes Mac OSx feels like
>>> it starts on PC with EFI). What Virtual Box does it has started
>>> supporting the modern PC architecture and as result you can take original
>>> Mac OSx
>>> (as far as I know it possible to buy Snow Leopard legally in apple store)
>>> and install it as virtual machine. Of course, there are still several
>>> problems, your hardware (CPU/GPU/etc) should be compatible with what Mac
>>> OSx can support.
>>>
>>>
>>>
>> AFAIK none of the Geany developers uses Macs so there is no reason for
>> anyone to spend money do it.
>>
>> But if you can help we are happy to provide all the guidance we can if you
>> can contribute by looking at the problem.
>>
>> If you get a chance to look at when the 100% starts would be good.
>>
>> As I said in a post a couple back to Enrico (I see I didn't clearly
>> indicate I was talking to him, oops sorry) if the problem can't be
>> definitely found, another option is to try the way builds are run on
>> Windows, where they are synchronous and different methods are used to
>> interface to the subprocess. So all is not lost yet.
>>
>> To answer your question about where to look, all is in build.c, you will
>> see that there are #ifdefs that separate the windows and unix code, look at
>> the section headed "execute commands and handle results" and the whole
>> process starts at build_spawn_command(). If you can use a debugger to find
>> what loop its stuck in maybe we can narrow it down. I would assume its in
>> the GTK event/monitor loop, otherwise the application wouldn't continue to
>> work, possibly the monitor of the subprocess pipe isn't terminating right
>> and GTK keeps calling it with no characters??
>>
>> Cheers
>> Lex
>>
>>
>>
>> The only thing I can say right now is "build_iofunc()" executed
>> infinitely, the function always returns TRUE (that is the reason why it is
>> never terminated, I think).
>> Will see why ii is always true ...
>>
>>
>> Ok, thats where I thought it would be, I'm not sure why, maybe its
> GTK2.18 or OSX pipes but whatever, can you try the attached patch that tries
> to pick up more conditions to stop.
>
>
> Debugging indicated that the section below starts getting condition =
> G_IO_IN forever, but "g_io_channel_read_line" can read nothing.
> I have tried to use additional reading method like read_char,
> read_to_the_end. I have tried to flush pipe. None of it helped.
> The result workaround I have used shown below:
>
> if (cond & (G_IO_IN | G_IO_PRI))
> {
> gchar *msg;
> + int count = 0;
>
> while (g_io_channel_read_line(ioc, &msg, NULL, NULL, NULL) && msg)
> {
> gint color = (GPOINTER_TO_INT(data)) ? COLOR_DARK_RED : COLOR_BLACK;
>
> process_build_output_line(msg, color);
> g_free(msg);
> + count++
> }
>
> + if (count == 0) return FALSE;
> }
>
>
> It works, but doesn't give an answer why pipe says "there is still
> something to read in the pipe".
>
>
>
Hmmmmm....
Did you have a chance to test the patch that checks the return from
g_io_channel_read_line?
Cheers
Lex
>
>
> _______________________________________________
> Geany mailing list
> Geany at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geany.org/pipermail/users/attachments/20100521/d477cdcf/attachment.html>
More information about the Users
mailing list