Getting "SIGPROF - Profiling timer expired error" when we invoke collect command on a program

Some thoughts:
 
  - not all Linuxes are fully supported.  Adding the version and kernel number to this post might be helpful.
 
  - collect may not have been tested with daemons.  Are you actually interested in haproxy itself, or some other process?  It could be that collect is having problems "following" the various forks/spawns to get to the process of interest.

  - What is the username listed for the process you actually want to measure?  Is that process a descendent of haproxy?  If root is involved, collect might be running into file permission problems.  For example, if a user process creates the parent experiment, and root subprocess then tries to write a subexperiment, it may fail with access permissions.
 
  -  In case you are tempted to try  -P to attach to a running PID:  attach to multithreaded processes only works on Solaris.  If possible, I'd avoid the -P <pid> option on Linux.

  - Running collect with several tracing options enabled, in particular (-i, -H), may not give you very useful results since each introduces significant overhead.  Note that collect's most common use-case is time profiling ("collect -p"), so I'd try to get that working first.
 
  - It can be helpful to write experiments to a fast file system (e.g. -d /tmp) in order to get more accurate performance results.
 
  - By default, a binary archiving step occurs during collect; it can be turned off to aid in debugging with -A off.  (Post-run archiving can be done with er_archive).
 
  - Inside each experiment is a file called log.xml. The data includes collect version, options, start/stop times, errors, and info on descendent processes.  If you have descendent processes, there will also be subexperiments, each with a log.xml.  Take a look at the log.xml files to see if they make sense.  You can ask for help decoding the contents.
 
 
So... maybe start with the simplest data collection options on a simple app that just does some busy work. E.g.
 
    collect -d /tmp -A off <my_standalone_app>
 
If that works try your application (/etc/init.d/haproxy)

    collect -d /tmp -A off /etc/init.d/haproxy start

If the application seems to stop early, take a look at the log.xml files, and compare that to the descendent processes you expect.

You can also look at the experiment in Analyzer's timeline to see if it jives with the log.xml files.

If haproxy run succeeds and the process is actually multithreaded, you could then try adding "-s on". 
 
    collect -d /tmp -A off -s on /etc/init.d/haproxy start

Finally, if you really need the data, you could try one tracing option (-i or -H) at a time, and possibly without -s or -p.   Runs longer than a few minutes can create very large experiments that take a long time to load.