1

I'm using the mail gem to parse a set of emails. Unfortunately one of the emails causes the parse to hit 100% CPU and never returns.

I have been using ruby-prof and the benchmarking tools to look at the mail gem in general but my question is how do I profile and figure out what is going wrong without the script ever returning.

Unfortunately I don't know how to reproduce this error and the message that I have is confidential so I cannot share it. From what I can see there is nothing special about it however and it's only 4mb large when 30mb emails can parse fine.

Thanks!

Steve Smith
  • 5,146
  • 1
  • 30
  • 31
  • 2
    Infinite (or very long-running) loops are the easiest thing to find, assuming you have the source and are running in a debug environment. You just pause it (by Ctrl-C or whatever). You know the problem is somewhere on the stack. Then just start single-stepping until you see the problem. – Mike Dunlavey Feb 15 '11 at 01:23

1 Answers1

1

You must use any debbuger, and debug step by step and see where is the line of code that is critical. For example for php apps I use Zend Studio for debuging. Alban

albanx
  • 6,193
  • 9
  • 67
  • 97
  • 2
    I'm not very experienced with rdebug, but with **gdb** you can press `ctrl+c` while the app is executing, and it opens de debug console. – Augusto Feb 14 '11 at 23:05
  • I don't know why I didn't think to do this. I fairly often use ruby-debug I just assumed that because of the number of calls and the general issues that I would need to profile to see where the issue was but stepping through might actually work! – Steve Smith Feb 14 '11 at 23:42
  • 1
    @Steve: That's just an extreme case of [this technique](http://stackoverflow.com/questions/375913/what-can-i-use-to-profile-c-code-in-linux/378024#378024). – Mike Dunlavey Feb 15 '11 at 01:26
  • 1
    Thanks guys. You were right this was absolutely the easiest thing to find once I knew what I was doing. Exiting from ruby using ctrl-c showed the stack trace. Doing that a couple of times highlighted where the error was. Then it was just a case of debugging around that area. – Steve Smith Feb 15 '11 at 11:44
  • @Steve: Just curious. Was the problem at the bottom of the stack or somewhere in the middle? – Mike Dunlavey Feb 15 '11 at 14:31
  • @Mike: It varied depending on exactly where I was when I stopped it in this case but it was fairly easy to debug. It turned out the mail was just doing far more processing that I expected. The mail didn't have a gap between headers and body (something I should have spotted) this caused each line of the body to be treated as a header and parsing went from < 3 secs to > 20 mins. I have altered the mail gem to only work with the first 1000 lines of headers and everything works great – Steve Smith Feb 15 '11 at 15:23
  • @Steve: That agrees with my experience that performance problems are more like bugs than bad algorithms or things that measuring or sampling the PC alone would find. Thanks. – Mike Dunlavey Feb 15 '11 at 16:14