I think you need to use the -g flag to get symbolic information.
> On Feb 25, 2015, at 11:06 AM, Phil Rosenberg <p.d.rosenb...@gmail.com> wrote: > > Hi Jim > Here is the backtrace. I had thought that setting CMAKE_C_FLAGS to -d > would give line numbers, but apparently it doesn't, so the backtrace > just has addresses > > *** glibc detected *** examples/c++/x13: double free or corruption > (!prev): 0x0000000001fcb720 *** > ======= Backtrace: ========= > /lib64/libc.so.6[0x3a5d075e66] > /lib64/libc.so.6[0x3a5d0789b3] > /nfs/see-fs-02_users/earpros/usr/src/plplot-phil/build/src/libplplot.so.12(plP_fill+0x9c)[0x7fef64a07edc] > /nfs/see-fs-02_users/earpros/usr/src/plplot-phil/build/src/libplplot.so.12(plP_plfclp+0xeed)[0x7fef64a18b3d] > /nfs/see-fs-02_users/earpros/usr/src/plplot-phil/build/src/libplplot.so.12(c_plfill+0x152)[0x7fef64a17b82] > examples/c++/x13(main+0x482)[0x401ce2] > /lib64/libc.so.6(__libc_start_main+0xfd)[0x3a5d01ed5d] > examples/c++/x13[0x401799] > ======= Memory map: ======== > 00400000-00420000 r-xp 00000000 00:1a 204350686 > /nfs/see-fs-02_users/earpros/usr/src/plplot-phil/build/examples/c++/x13 > 00620000-00621000 rw-p 00020000 00:1a 204350686 > /nfs/see-fs-02_users/earpros/usr/src/plplot-phil/build/examples/c++/x13 > 01fad000-0201d000 rw-p 00000000 00:00 0 > [heap] > 3a5cc00000-3a5cc20000 r-xp 00000000 fd:00 392467 > /lib64/ld-2.12.so > 3a5ce1f000-3a5ce20000 r--p 0001f000 fd:00 392467 > /lib64/ld-2.12.so > 3a5ce20000-3a5ce21000 rw-p 00020000 fd:00 392467 > /lib64/ld-2.12.so > 3a5ce21000-3a5ce22000 rw-p 00000000 00:00 0 > 3a5d000000-3a5d18a000 r-xp 00000000 fd:00 392471 > /lib64/libc-2.12.so > 3a5d18a000-3a5d38a000 ---p 0018a000 fd:00 392471 > /lib64/libc-2.12.so > 3a5d38a000-3a5d38e000 r--p 0018a000 fd:00 392471 > /lib64/libc-2.12.so > 3a5d38e000-3a5d38f000 rw-p 0018e000 fd:00 392471 > /lib64/libc-2.12.so > 3a5d38f000-3a5d394000 rw-p 00000000 00:00 0 > 3a5d400000-3a5d483000 r-xp 00000000 fd:00 414983 > /lib64/libm-2.12.so > 3a5d483000-3a5d682000 ---p 00083000 fd:00 414983 > /lib64/libm-2.12.so > 3a5d682000-3a5d683000 r--p 00082000 fd:00 414983 > /lib64/libm-2.12.so > 3a5d683000-3a5d684000 rw-p 00083000 fd:00 414983 > /lib64/libm-2.12.so > 3a5d800000-3a5d802000 r-xp 00000000 fd:00 392497 > /lib64/libdl-2.12.so > 3a5d802000-3a5da02000 ---p 00002000 fd:00 392497 > /lib64/libdl-2.12.so > 3a5da02000-3a5da03000 r--p 00002000 fd:00 392497 > /lib64/libdl-2.12.so > 3a5da03000-3a5da04000 rw-p 00003000 fd:00 392497 > /lib64/libdl-2.12.so > 3a5dc00000-3a5dc17000 r-xp 00000000 fd:00 392476 > /lib64/libpthread-2.12.so > 3a5dc17000-3a5de17000 ---p 00017000 fd:00 392476 > /lib64/libpthread-2.12.so > 3a5de17000-3a5de18000 r--p 00017000 fd:00 392476 > /lib64/libpthread-2.12.so > 3a5de18000-3a5de19000 rw-p 00018000 fd:00 392476 > /lib64/libpthread-2.12.so > 3a5de19000-3a5de1d000 rw-p 00000000 00:00 0 > 3a5f000000-3a5f002000 r-xp 00000000 fd:00 1724025 > /usr/lib64/libXau.so.6.0.0 > 3a5f002000-3a5f202000 ---p 00002000 fd:00 1724025 > /usr/lib64/libXau.so.6.0.0 > 3a5f202000-3a5f203000 rw-p 00002000 fd:00 1724025 > /usr/lib64/libXau.so.6.0.0 > 3a5f400000-3a5f537000 r-xp 00000000 fd:00 1724027 > /usr/lib64/libX11.so.6.3.0 > 3a5f537000-3a5f737000 ---p 00137000 fd:00 1724027 > /usr/lib64/libX11.so.6.3.0 > 3a5f737000-3a5f73d000 rw-p 00137000 fd:00 1724027 > /usr/lib64/libX11.so.6.3.0 > 3a5f800000-3a5f81d000 r-xp 00000000 fd:00 1724026 > /usr/lib64/libxcb.so.1.1.0 > 3a5f81d000-3a5fa1d000 ---p 0001d000 fd:00 1724026 > /usr/lib64/libxcb.so.1.1.0 > 3a5fa1d000-3a5fa1e000 rw-p 0001d000 fd:00 1724026 > /usr/lib64/libxcb.so.1.1.0 > 3a60c00000-3a60c16000 r-xp 00000000 fd:00 414985 > /lib64/libgcc_s-4.4.7-20120601.so.1 > 3a60c16000-3a60e15000 ---p 00016000 fd:00 414985 > /lib64/libgcc_s-4.4.7-20120601.so.1 > 3a60e15000-3a60e16000 rw-p 00015000 fd:00 414985 > /lib64/libgcc_s-4.4.7-20120601.so.1 > 3a61400000-3a614e8000 r-xp 00000000 fd:00 1723983 > /usr/lib64/libstdc++.so.6.0.13 > 3a614e8000-3a616e8000 ---p 000e8000 fd:00 1723983 > /usr/lib64/libstdc++.so.6.0.13 > 3a616e8000-3a616ef000 r--p 000e8000 fd:00 1723983 > /usr/lib64/libstdc++.so.6.0.13 > 3a616ef000-3a616f1000 rw-p 000ef000 fd:00 1723983 > /usr/lib64/libstdc++.so.6.0.13 > 3a616f1000-3a61706000 rw-p 00000000 00:00 0 > 3a61c00000-3a61c04000 r-xp 00000000 fd:00 415005 > /lib64/libuuid.so.1.3.0 > 3a61c04000-3a61e03000 ---p 00004000 fd:00 415005 > /lib64/libuuid.so.1.3.0 > 3a61e03000-3a61e04000 rw-p 00003000 fd:00 415005 > /lib64/libuuid.so.1.3.0 > 3a62000000-3a62017000 r-xp 00000000 fd:00 1724043 > /usr/lib64/libICE.so.6.3.0 > 3a62017000-3a62217000 ---p 00017000 fd:00 1724043 > /usr/lib64/libICE.so.6.3.0 > 3a62217000-3a62218000 rw-p 00017000 fd:00 1724043 > /usr/lib64/libICE.so.6.3.0 > 3a62218000-3a6221c000 rw-p 00000000 00:00 0 > 3a62c00000-3a62c07000 r-xp 00000000 fd:00 1724044 > /usr/lib64/libSM.so.6.0.1 > 3a62c07000-3a62e07000 ---p 00007000 fd:00 1724044 > /usr/lib64/libSM.so.6.0.1 > 3a62e07000-3a62e08000 rw-p 00007000 fd:00 1724044 > /usr/lib64/libSM.so.6.0.1 > 3a64000000-3a64011000 r-xp 00000000 fd:00 1724035 > /usr/lib64/libXext.so.6.4.0 > 3a64011000-3a64211000 ---p 00011000 fd:00 1724035 > /usr/lib64/libXext.so.6.4.0 > 3a64211000-3a64212000 rw-p 00011000 fd:00 1724035 > /usr/lib64/libXext.so.6.4.0 > 3a6b000000-3a6b009000 r-xp 00000000 fd:00 1730614 > /usr/lib64/libltdl.so.7.2.1 > 3a6b009000-3a6b208000 ---p 00009000 fd:00 1730614 > /usr/lib64/libltdl.so.7.2.1 > 3a6b208000-3a6b209000 rw-p 00008000 fd:00 1730614 > /usr/lib64/libltdl.so.7.2.1 > 7fef626d7000-7fef626d8000 ---p 00000000 00:00 0 > 7fef626d8000-7fef630d8000 rw-p 00000000 00:00 0 > 7fef630d8000-7fef630e7000 r-xp 00000000 00:1a 193473707 > /nfs/see-fs-02_users/earpros/usr/src/plplot-phil/build/drivers/xwin.so > 7fef630e7000-7fef632e6000 ---p 0000f000 00:1a 193473707 > /nfs/see-fs-02_users/earpros/usr/src/plplot-phil/build/drivers/xwin.soAbort > > > running it under gdb shows that it fills a small triangle with an > incorrect hatch pattern before segfaulting. Of course plplot might > have rendered more than this as it depends when the bitmap got blt'd > to the dc/screen. > > Phil > >> On 25 February 2015 at 14:57, Jim Dishaw <j...@dishaw.org> wrote: >> Would you send the backtrace and line number where the error occurs. >> >> I wonder if filling in a curved area is overflowing the control point array? >> I'm grasping at straws. >> >> >> >>> On Feb 25, 2015, at 8:40 AM, Phil Rosenberg <p.d.rosenb...@gmail.com> wrote: >>> >>> Hi Jim >>> I doubt there are very many control points example 13 is just a simple >>> pie chart. The crash is immediate, not on a redraw. I wondered if it >>> could be related to overflowing some buffer when writing to the >>> plbuffer as this writing occurs during plP_fill - it only happens when >>> a hatching is used as the fill pattern so I assume there is something >>> specific happening related to the fill pattern. >>> >>> Another possibility would be that the call to set the fill pattern >>> corrupts the memory and it just happens to be in plP_fill that this >>> corrupted memry finally causes a segfault - perhaps this is the next >>> buffer write or memory allocation after the corruption or something. >>> >>> Phil ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
