From: Hazen B. <hba...@ma...> - 2009-08-30 16:23:19
|
In the process of investigating cmap issues Alan and Werner were discussing I have found that the xcairo driver no longer works on my PowerPC OS-X box, and instead fails with a "Bus error". The other cairo drivers such as the ps and png drivers work fine. I just updated to Cairo 1.8.8 and that did not seem to rectify things. Maybe I have too old a version of X11? Perhaps it has something to do with the off-screen rendering changes? pkg-config --modversion cairo 1.8.8 uname -a Darwin hazen-babcocks-imac-g5.local 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc X11 1.1.3 - XFree86 4.4.0 -Hazen |
From: Hezekiah M. C. <hez...@us...> - 2009-08-31 13:22:45
|
On Sun, Aug 30, 2009 at 11:23 AM, Hazen Babcock<hba...@ma...> wrote: > > In the process of investigating cmap issues Alan and Werner were > discussing I have found that the xcairo driver no longer works on my > PowerPC OS-X box, and instead fails with a "Bus error". The other cairo > drivers such as the ps and png drivers work fine. I just updated to > Cairo 1.8.8 and that did not seem to rectify things. Maybe I have too > old a version of X11? Perhaps it has something to do with the off-screen > rendering changes? > > pkg-config --modversion cairo > 1.8.8 > > uname -a > Darwin hazen-babcocks-imac-g5.local 8.11.0 Darwin Kernel Version 8.11.0: > Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power > Macintosh powerpc > > X11 1.1.3 - XFree86 4.4.0 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 -- Hezekiah M. Carty Graduate Research Assistant University of Maryland Department of Atmospheric and Oceanic Science |
From: Hazen B. <hba...@ma...> - 2009-09-03 14:07:25
|
Hezekiah M. Carty wrote: > On Sun, Aug 30, 2009 at 11:23 AM, Hazen Babcock<hba...@ma...> wrote: >> In the process of investigating cmap issues Alan and Werner were >> discussing I have found that the xcairo driver no longer works on my >> PowerPC OS-X box, and instead fails with a "Bus error". The other cairo >> drivers such as the ps and png drivers work fine. I just updated to >> Cairo 1.8.8 and that did not seem to rectify things. Maybe I have too >> old a version of X11? Perhaps it has something to do with the off-screen >> rendering changes? >> >> pkg-config --modversion cairo >> 1.8.8 >> >> uname -a >> Darwin hazen-babcocks-imac-g5.local 8.11.0 Darwin Kernel Version 8.11.0: >> Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power >> Macintosh powerpc >> >> X11 1.1.3 - XFree86 4.4.0 > > 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. So, it turns out it is has nothing to do with your recent changes. I've seen this problem before on OS-X but since I don't use my mac much these days for dev work I had forgotten about it. Basically, with some drivers, if you try and specify them at the command prompt with "./example/x -dev driverx" then they will give a bus error. However, if you just run "./example/x" and the choose the driver from the list everything works. Since this issue has been around for years and I'm the only one who seems to struggle with it I'm not inclined to delay the release until it gets sorted out. -Hazen |
From: Alan W. I. <ir...@be...> - 2009-09-03 15:50:43
|
On 2009-09-03 10:07-0400 Hazen Babcock wrote: >> On Sun, Aug 30, 2009 at 11:23 AM, Hazen Babcock<hba...@ma...> wrote: >>> In the process of investigating cmap issues Alan and Werner were >>> discussing I have found that the xcairo driver no longer works on my >>> PowerPC OS-X box, and instead fails with a "Bus error". The other cairo >>> drivers such as the ps and png drivers work fine. > [...]it turns out it is has nothing to do with [...]recent changes. I've > seen this problem before on OS-X but since I don't use my mac much these > days for dev work I had forgotten about it. Basically, with some > drivers, if you try and specify them at the command prompt with > "./example/x -dev driverx" then they will give a bus error. However, if > you just run "./example/x" and the choose the driver from the list > everything works. Hi Hazen: It sounds like you have discovered (or rediscovered) an issue in the command-line parsing code on your OS X platform. Could you remind us again of exactly what hardware that is (32-bit or 64-bit, PowerPC or Intel)? I looked up bus error at http://en.wikipedia.org/wiki/Bus_error, and it appears to have two general causes. The first of those seems closely related to segfaults and memory management and the second of these has to do with memory alignment (which might be screwed up in the command-line parsing code for big-endian architectures like PowerPC, but not little-endian architectures like Intel). Generally with all such errors I suggest you use valgrind to help figure things out. So do you get valgrind error reports for all command-line options or just -dev.? If just -dev, is it for all devices or just the ones that produce bus errors? 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 __________________________ |
From: Werner S. <sm...@ia...> - 2009-09-03 18:49:19
|
Hi, > > It sounds like you have discovered (or rediscovered) an issue in the > command-line parsing code on your OS X platform. Could you remind > us again > of exactly what hardware that is (32-bit or 64-bit, PowerPC or Intel)? PowerPC, 32 bit AFAIR. That's also a problem for valgrind, since according due http://valgrind.org/ is there only a valgrind port for Intel/Darwin available. I don't see such problems on Mac OS X 10.5, Intel. Is gdb of any help? Regards, Werner > > I looked up bus error at http://en.wikipedia.org/wiki/Bus_error, and > it > appears to have two general causes. The first of those seems closely > related to segfaults and memory management and the second of these > has to do > with memory alignment (which might be screwed up in the command-line > parsing > code for big-endian architectures like PowerPC, but not little-endian > architectures like Intel). > > Generally with all such errors I suggest you use valgrind to help > figure > things out. So do you get valgrind error reports for all command-line > options or just -dev.? If just -dev, is it for all devices or just > the ones > that produce bus errors? > > 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 > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria DVR-Nr: 0005886 email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Alan W. I. <ir...@be...> - 2009-09-03 17:20:52
|
Hi Hazen: Your comment below got me thinking about this new subject. On 2009-09-03 10:07-0400 Hazen Babcock wrote: > Since this [command-line parsing] issue has been around for years and I'm the > only one who seems to struggle with it I'm not inclined to delay the > release until it gets sorted out. On the whole, I prefer to stick to release dates once we set them, but in this case of four (!) issues that affect our premier devices it may be better for us to back off and release a week later instead depending on whether there is a good chance an extra week would allow us to sort out some of these issues. Let me know what you think about this. Here are those issues again: (1) The above command-line parsing issue. The valgrind investigations I suggested for this case may allow you to find the reason for this error and fix it in a relatively small amount of time. Do you have time to work on this before the weekend of September 12th/13th? (2) plend/qt segfaults on some platforms. This one is still pretty open ended, but Alban appears to be actively investigating it so he might well benefit by a week's delay in the release. (3) plend/xcairo segfaults on all (?) platforms. Certainly, I see this issue on my platform. Hez, are you working on this one? (4) locale/qt issue which have not been fixed in the best way, yet, IMO. I believe we can find the right solution before September 12th/13th. We all can only work on PLplot part time so a day of actual work may easily stretch to several days of real time. So (4) is very likely to benefit from a week's delay in the release, and some or all of the rest of the issues might benefit as well depending on how much time our various developers have to track down and fix these issues in the extra time provided by a week's delay in the release. I don't think we should delay the release by much more than a week though since if a week's part-time effort doesn't solve these issues, then throwing more time at it may not help much either. Hazen, would releasing during the weekend of September 12/13th be convenient for you? If not or if you or others here don't feel a week's delay in the release would help to solve the above issues for our best devices, then despite those issues I would be willing to go along with the scheduled release this weekend (September 5th/6th). 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2009-09-04 18:30:18
|
On 2009-09-03 10:20-0700 Alan W. Irwin wrote: > Here are those issues again: > > (1) The above command-line parsing issue. The valgrind investigations I > suggested for this case may allow you to find the reason for this error and > fix it in a relatively small amount of time. Do you have time to work on > this before the weekend of September 12th/13th? > > (2) plend/qt segfaults on some platforms. This one is still pretty open > ended, but Alban appears to be actively investigating it so he might > well benefit by a week's delay in the release. > > (3) plend/xcairo segfaults on all (?) platforms. Certainly, I see this > issue on my platform. Hez, are you working on this one? > > (4) locale/qt issue which have not been fixed in the best way, yet, IMO. > I believe we can find the right solution before September 12th/13th. > Thanks to Hazen and Hez for responding to my question. With regard to (1) it would be nice for Hazen to deal with this before the release (with gdb following Hez's suggestion about specifying command-line options to the gdb run command), but it appears to be an isolated problem and therefore not release critical. With regard to (2) from Alban's continuing experiments and especially from the good results he gets if he builds Qt4 himself, it is beginning to look like this test_plend issue is due to a distro packaging issue for Qt4 rather than anything wrong with our qt device driver. With regard to (3) nobody appears to be working on this issue at the moment, but (a) it might well take quite a while to fix it or (b) it might be an external library logic or building error which we could do nothing about (except file a bug report). With regard to (4) I think I am finally on the right track (see my response to Arjen's comments about LC_NUMERIC) so I hope to finish that today. So I now agree with Hazen and Hez we could/should release either tomorrow or Sunday. Hazen, please let us know on list the day you plan to do the release this weekend once you have finalized a convenient time to do that. 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 __________________________ |
From: Hazen B. <hba...@ma...> - 2009-09-04 16:49:37
|
Alan W. Irwin wrote: > Hi Hazen: > > Your comment below got me thinking about this new subject. > > On 2009-09-03 10:07-0400 Hazen Babcock wrote: > >> Since this [command-line parsing] issue has been around for years and I'm the >> only one who seems to struggle with it I'm not inclined to delay the >> release until it gets sorted out. > > On the whole, I prefer to stick to release dates once we set them, but in > this case of four (!) issues that affect our premier devices it may be > better for us to back off and release a week later instead depending on > whether there is a good chance an extra week would allow us to sort out > some of these issues. Let me know what you think about this. > > Here are those issues again: > > (1) The above command-line parsing issue. The valgrind investigations I > suggested for this case may allow you to find the reason for this error and > fix it in a relatively small amount of time. Do you have time to work on > this before the weekend of September 12th/13th? I can try, but since I am the only one who seems to run into this problem and I have a pretty vintage OS-X box (32bit PowerPC, OS-X 10.4) at this point, I don't attach much importance to it. Also, remember that this only effects the xcairo and aqt drivers. I guess if I could figure out how to pass command line arguments using gdb I'd be willing to try that and see what happens. > (2) plend/qt segfaults on some platforms. This one is still pretty open > ended, but Alban appears to be actively investigating it so he might > well benefit by a week's delay in the release. > > (3) plend/xcairo segfaults on all (?) platforms. Certainly, I see this > issue on my platform. Hez, are you working on this one? I thought that all the cairo drivers had this issue? I'd be really surprised if we could solve this one in a week though given how long it has been with us. My recollection is that problem goes away if we don't use dynamic drivers or if we don't render any text, suggesting some mixture of Pango, dynamics drivers and loading/unloading libltdl resources. > (4) locale/qt issue which have not been fixed in the best way, yet, IMO. > I believe we can find the right solution before September 12th/13th. > > We all can only work on PLplot part time so a day of actual work may easily > stretch to several days of real time. So (4) is very likely to benefit from > a week's delay in the release, and some or all of the rest of the issues > might benefit as well depending on how much time our various developers have > to track down and fix these issues in the extra time provided by a week's > delay in the release. I don't think we should delay the release by much more > than a week though since if a week's part-time effort doesn't solve these > issues, then throwing more time at it may not help much either. > > Hazen, would releasing during the weekend of September 12/13th be convenient > for you? If not or if you or others here don't feel a week's delay in the > release would help to solve the above issues for our best devices, then > despite those issues I would be willing to go along with the scheduled > release this weekend (September 5th/6th). Either weekend is fine with me. -Hazen |
From: Hezekiah M. C. <hez...@us...> - 2009-09-04 17:18:40
|
On Fri, Sep 4, 2009 at 11:49 AM, Hazen Babcock<hba...@ma...> wrote: > Alan W. Irwin wrote: >> (1) The above command-line parsing issue. The valgrind investigations I >> suggested for this case may allow you to find the reason for this error and >> fix it in a relatively small amount of time. Do you have time to work on >> this before the weekend of September 12th/13th? > > I can try, but since I am the only one who seems to run into this > problem and I have a pretty vintage OS-X box (32bit PowerPC, OS-X 10.4) > at this point, I don't attach much importance to it. Also, remember that > this only effects the xcairo and aqt drivers. I guess if I could figure > out how to pass command line arguments using gdb I'd be willing to try > that and see what happens. To pass command line arguments in gdb, add them to the "run" command. For example: $ gdb ./x01c <gdb copyright and other output> (gdb) run -dev xcairo That should be equivalent to running "./x01c -dev xcairo" >> (3) plend/xcairo segfaults on all (?) platforms. Certainly, I see this >> issue on my platform. Hez, are you working on this one? > > I thought that all the cairo drivers had this issue? I'd be really > surprised if we could solve this one in a week though given how long it > has been with us. My recollection is that problem goes away if we don't > use dynamic drivers or if we don't render any text, suggesting some > mixture of Pango, dynamics drivers and loading/unloading libltdl resources. These points are all true, from what I have seen and remember. If one avoids text then there is no segmentation fault on any platform I have tested. Also, last I checked, this does not occur on Fedora. It has been a while since I have tested this particular issue there though. I agree with Hazen that it is not currently worth delaying the release for this. It is a bad problem, but I don't think an extra week will make much of a difference in this case. Hez -- Hezekiah M. Carty Graduate Research Assistant University of Maryland Department of Atmospheric and Oceanic Science |
From: Hazen B. <hba...@ma...> - 2009-09-04 18:39:52
|
Alan W. Irwin wrote: > On 2009-09-03 10:20-0700 Alan W. Irwin wrote: > >> Here are those issues again: >> >> (1) The above command-line parsing issue. The valgrind investigations I >> suggested for this case may allow you to find the reason for this error and >> fix it in a relatively small amount of time. Do you have time to work on >> this before the weekend of September 12th/13th? >> >> (2) plend/qt segfaults on some platforms. This one is still pretty open >> ended, but Alban appears to be actively investigating it so he might >> well benefit by a week's delay in the release. >> >> (3) plend/xcairo segfaults on all (?) platforms. Certainly, I see this >> issue on my platform. Hez, are you working on this one? >> >> (4) locale/qt issue which have not been fixed in the best way, yet, IMO. >> I believe we can find the right solution before September 12th/13th. >> > > Thanks to Hazen and Hez for responding to my question. > > With regard to (1) it would be nice for Hazen to deal with this before the > release (with gdb following Hez's suggestion about specifying command-line > options to the gdb run command), but it appears to be an isolated problem > and therefore not release critical. > > With regard to (2) from Alban's continuing experiments and especially from > the good results he gets if he builds Qt4 himself, it is beginning to look > like this test_plend issue is due to a distro packaging issue for Qt4 rather > than anything wrong with our qt device driver. > > With regard to (3) nobody appears to be working on this issue at the moment, > but (a) it might well take quite a while to fix it or (b) it might be an > external library logic or building error which we could do nothing about > (except file a bug report). > > With regard to (4) I think I am finally on the right track (see my response > to Arjen's comments about LC_NUMERIC) so I hope to finish that today. > > So I now agree with Hazen and Hez we could/should release either tomorrow or > Sunday. > > Hazen, please let us know on list the day you plan to do the release this > weekend once you have finalized a convenient time to do that. I'll release on Sunday. I'll look at issue (1) tomorrow and see how it goes. -Hazen |
From: Hazen B. <hba...@ma...> - 2009-09-06 00:08:34
|
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? -Hazen |
From: Alan W. I. <ir...@be...> - 2009-09-06 02:05:34
|
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 __________________________ |
From: Alan W. I. <ir...@be...> - 2009-09-06 03:02:45
|
On 2009-09-05 19:05-0700 Alan W. Irwin wrote: > If you have any further questions about how to use gdb, don't hesitate to > ask for help on this list. Also, you might want to try one of the gdb tutorials you can find with a google search. One of those I just looked at (for the first time) is http://www.unknownroad.com/rtfm/gdbtut/gdbtoc.html. It looks pretty good and seems to cover everything I said and a bit more without being overwhelming. 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 __________________________ |