On 2009-09-05 20:08-0400 Hazen Babcock wrote:

> Hezekiah M. Carty wrote:
>>
>> Hazen,
>>
>> Is there any way you could get a backtrace on this from gdb or
>> otherwise?  I do not have access to a PPC Mac to test on at this time
>> and a search on Google for "cairo bus error" gives lots of OSX-related
>> results but no answer that seems obvious to me.
>>
>> Does example 20 work with other Cairo devices on your PPC OSX system?
>> plimage/plimagefr + any Cairo device uses a similar offscreen
>> rendering method to rasterize the plotted image.  That code has been
>> in Subversion since late May and has no specific ties to X or xcairo.
>>
>> Hez
>
> Thanks for your help with gdb. Here is the backtrace:
>
> (gdb) run -dev xcairo
> Starting program:
> /Users/hbabcock/Documents/OpenSource/PLplot/plplot-CBS-1/examples/c/x01c
> -dev xcairo
> Reading symbols for shared libraries ..+.++++ done
> PLplot library version: 5.9.4
> Reading symbols for shared libraries
> ..................................................................... done
>
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
> 0x90131280 in memcmp ()
> (gdb) bt
> #0  0x90131280 in memcmp ()
> #1  0x907f4640 in __CFInitialize ()
> #2  0x8fe155e0 in
> __dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE
> ()
> #3  0x8fe0babc in
> __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextE ()
> #4  0x8fe0ba4c in
> __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextE ()
> #5  0x8fe0ba4c in
> __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextE ()
> #6  0x8fe0ba4c in
> __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextE ()
> #7  0x8fe0ba4c in
> __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextE ()
> #8  0x8fe0ba4c in
> __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextE ()
> #9  0x8fe0ba4c in
> __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextE ()
> #10 0x8fe0dcdc in
> __dyld__ZN11ImageLoader4linkERKNS_11LinkContextENS_15BindingLazinessENS_18InitializerRunningEj
> ()
> #11 0x8fe04070 in
> __dyld__ZN4dyld4linkEP11ImageLoaderNS0_15BindingLazinessENS0_18InitializerRunningE
> ()
> #12 0x8fe09b00 in __dyld_dlopen ()
> #13 0x90030cf4 in dlopen ()
> #14 0x960c2318 in sys_dl_open ()
> #15 0x960c2d90 in tryall_dlopen ()
> #16 0x960c6100 in try_dlopen ()
> #17 0x960c64e0 in lt_dlopenext ()
> #18 0x0008c6d8 in plLoadDriver ()
> #19 0x0008b318 in pllib_devinit ()
> #20 0x0008958c in c_plinit ()
> #21 0x00089448 in c_plstar ()
> #22 0x00003a7c in main ()
>
> Looks like another dynamic libraries problem?

First in order to properly debug with gdb you have to compile the PLplot
library with the -g option.  One way to do that is to set

export CC='gcc -g'

just before a fresh cmake command.

To debug this further you have to insert break points just before the error
and see what is causing it. To start that process, you should insert a break
point (gdb "break" command", and for help with that use the gdb "help break"
command) just before the call to lt_dlopenext and carefully compare all
arguments to lt_dlopenext for the "run" case (where you respond to the
PLplot library prompt for device name with "xcairo") and the "run -dev
xcairo" case.

According to what you have said before the former has no bus errors while
the latter does. So it is likely you will see some key difference between
the arguments of lt_dlopenext in the two cases.

If you look at the code in plargs.c, -dev xcairo simply calls
plsdev which (from plcore.c) sets up plsc->DevName.  Then when the
example calls plinit, that calls pllib_devinit which calls
plSelectDev which does some kind of check on
plsc->DevName to decide whether it needs to prompt the user for a device.
Then pllib_devinit calls plLoadDriver which calls lt_dlopenext which
generates the error in the "run -dev xcairo" case but not in the "run" case.

The key difference between the two ways of specifying the device is what
happens in plSelectDev.  I would put break points in there, single step
through the code (using the gdb "next" command), and print out results with
the gdb "print" command until you spot what is going wrong for
the "run -dev xcairo" case.

If you have any further questions about how to use gdb, don't hesitate to
ask for help on this list.  There are lots of experts in its use here as
well as those like me with a working knowledge built up by looking a lot at
gdb documentation ("info gdb: on Linux) over the years as well as using the
help command from within gdb.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Reply via email to