[GRASS-user] Label crash

[Adam Dershowitz, Ph.D., P.E.]

On Apr 17, 2009, at 7:43 AM, Glynn Clements wrote:

>
> Markus Neteler wrote:
>
>>> If I generate a label:
>>> v.label map=Labels column=stuff font=/usr/X11R6/lib/X11/fonts/TTF/ 
>>> Vera.ttf
>>> then it displays fine in the gui.  But if I try to use other  
>>> monitors from
>>> the command line I consistently get a crash.  For example:
>>>
>>> d.mon start=PS
>>> d.labels labels=Labels
>>
>> I have tried with Spearfish, GRASS 6.4.0RC4, Linux 64bit:
>>
>> v.label  map=roads colum=label font=/usr/share/fonts/TTF/Vera.ttf
>> d.mon start=PS
>> d.labels labels=roads
>> d.mon stop=PS
>> kghostview map.ps
>>
>> No problem, looks fine.
>> It seems to be Mac specific.
>>
>>> And I get the following repeated a whole bunch of times:
>>>
>>> The process has forked and you cannot use this CoreFoundation  
>>> functionality
>>> safely. You MUST exec().
>>> Break on
>>> __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__ 
>>> ()
>>> to debug.
>>>
>>> The same thing happens if I use d.mon start=PNG.
>>
>> could fork() in
>> lib/driver/main.c
>> be the problem?
>
> Yes. It's basically a symptom of "MacOSX is sort of Unix, but not
> quite".

Actually MacOSX is Unix and Linux is almost Unix.

>
>
> A similar issue affects libW11 on Cygwin. There, mon.start runs the
> driver in the background (spawnl(_P_DETACH, ...)) with argv[2] = "-",
> which prevents it from fork()ing.
>
> Something similar could be done for MacOSX. However, this isn't
> robust, as it relies upon mon.select retrying upon failure. If the
> driver takes too long to start, mon.select will fail.
>

This explains the problem:  http://developer.apple.com/technotes/tn2005/tn2083.html#SECDAEMONVSFRAMEWORKS

Although I am not sure about the solution.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-user/attachments/20090417/c9ccd3ce/attachment.html