Josef, > What has this to do with "--demangle=no"? Even with "--demangle=no" (which makes a difference only for C++ symbols anyway), symbols should be printed > out just fine.
With --demangle=yes, Valgrind almost immediately ends up with a SIGSEGV and reports a problem with VG_(strcmp). With --demangle=no, Valgrind chugs along without generating a SIGSEGV. Since I use boost, python does dynamically generate very long C++ symbols (in some cases they fill up 5 lines). > As just mentioned, "--demangle=no" does not switch off the mapping of addresses to symbols, or influence this in any way. It is just about "pretty > printing" the symbols. With --demangle=yes, Valgrind generates a SIGSEGV almost immediately in VG_(strcmp) and with --demangle=no, it doesn't. "Pretty" symbols would have helped me get closer to a solution to my problem, but "ugly" symbols are not very helpful. > If your symbols do not show up with "--demangle=no", they also would not show up with "--demangle=yes". Actually, I do not think that Valgrind can map > symbols for dynamically generated code at all. I do get some symbol names that sometimes span multiple lines. In some cases, they show up with a substring "boost" in the very long symbol names. > Hmm. I even do not know how this should work. How does in work with GDB? I haven't used GDB yet. I will give that a shot today. SVG -----Original Message----- From: Josef Weidendorfer [mailto:josef.weidendor...@gmx.de] Sent: Wednesday, June 23, 2010 5:37 AM To: valgrind-users@lists.sourceforge.net Cc: Satya V. Gupta Subject: Re: [Valgrind-users] Running Valgrind on ELF/ python/ boost based executables On Wednesday 23 June 2010, Satya V. Gupta wrote: > Josef/ Julian > > The problem I have with --demangle=no is that: > > a) I am using Python to generate code dynamically and therefore, I > don't know of a good way of mapping symbols to addresses in a post > processing cycle. At every boot up cycle, the symbol name to address > location appears to be vastly different. What has this to do with "--demangle=no"? Even with "--demangle=no" (which makes a difference only for C++ symbols anyway), symbols should be printed out just fine. > b) My device runs into either an out of memory situation or ends up in > a SIGSEGV crash. As a result, no post processing method for recovering > symbols comes to my mind. As just mentioned, "--demangle=no" does not switch off the mapping of addresses to symbols, or influence this in any way. It is just about "pretty printing" the symbols. > Given these circumstances, if you are aware of any clever method of > recovering the symbols for dynamically generated code, please do let > me know and I shall gladly implement your suggestion. If your symbols do not show up with "--demangle=no", they also would not show up with "--demangle=yes". Actually, I do not think that Valgrind can map symbols for dynamically generated code at all. Hmm. I even do not know how this should work. How does in work with GDB? For Valgrind, we could introduce a client request notifying VG about any new generated code in the client, together with symbol names. Josef > > SVG > > > -----Original Message----- > From: Josef Weidendorfer [mailto:josef.weidendor...@gmx.de] > Sent: Monday, June 21, 2010 9:27 AM > To: valgrind-users@lists.sourceforge.net > Cc: Satya V. Gupta > Subject: Re: [Valgrind-users] Running Valgrind on ELF/ python/ boost > based executables > > On Thursday 17 June 2010, Satya V. Gupta wrote: > > Since you asked, I ran Valgrind with --demangle=no; the SIGSEGV > > issue I saw earlier went away. > > Very good. > > > However, I had gone to great lengths to insert symbol information > > into my image in order to chase down a run time issue I am having > > with the > code. > > Therefore, while running with --demangle=no is a good experiment, it > > is not a practical option for me. > > I have the exact same question as Julian here: what is your problem > with "--demangle=no"? It does not cut down any functionality. Symbols > will just show up demangled, which you can cope with in a > postprocessing step afterwards. > > > Is there another way in valgrind to restrict the string size offered > > to VG_(strcmp)() so that it won't crash? Can there be canary > > protection around the valgrind stack to protect it from being > > overrun in situations like these? > > For practical reasons, this seems next to impossible for me. > > Josef > > > > ____________________________________________________________ > TODAY: MacBooks for $24.78? > Special Report: Apple MacBooks are being auctionned at 85% off! > http://thirdpartyoffers.netzero.net/TGL3241/4c214fa46844849c983st04vuc > > ---------------------------------------------------------------------- > -------- ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental > unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Valgrind-users mailing list > Valgrind-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/valgrind-users > ____________________________________________________________ Get Free Email with Video Mail & Video Chat! http://www.netzero.net/freeemail?refcd=NZTAGOUT1FREM0210 ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
