Definitely something nasty in there, but not obvious what to me from those logs. I have applied your pulse fix to the p2os driver for the moment, it shouldn't cause any problems as it is reading as fast as it does with pulse mode off.

Toby

On 30/10/2007, Florian <aidos85@gmail.com> wrote:
Thanks toby and brian for taking the time to answer.

I tried running the CVS, but my autotool skills are close to nonexistent, and ./configure exits on a :

checking for javac... no
./configure: line 21518: syntax error near unexpected token `,'
./configure: line 21518: `    PKG_CHECK_MODULES(, ,'

I got Player to crash again, I'm attaching a valgrind trace and a gdb trace. The gdb trace says memory corruption, but sometimes it simply segfaults.

I also tried the "patch" with the SendReceive in both cases, it works great! And I don't notice any extra latency in playerv (when it was near unusable before). I attached a patch to p2os.cc, to show you what I changed. And now the bug doesn't trigger, so I'm gonna stick with that for the moment.

Thanks a lot!
Of course, if you need more traces etc, always happy to oblige ;)

Florian

2007/10/30, Brian Gerkey < brian@gerkey.org >:

On Oct 29, 2007, at 9:22 AM, Florian wrote:

>
> Sometimes it just segfaults after a while, sometimes it crashes
> with glibc complaining about memory corruption, and sometimes it
> runs fine. So there's clearly some pointer weirdness at work
> here... I also noticed that with the pulse option, player is always
> using 100% of the CPU whereas without it, it hardly uses any cpu
> cycles at all. Which makes sense when one looks at the code of
> p2oc.cc, because if the pulse option is on, then the Main loops
> around the delay check without ever pausing, whereas if pulse is no
> activated, then the Main does a blocking SendReceive, waiting for
> input. My guess is that you have a bug in the SIP class code
> somewhere, that triggers while you run with the pulse option,
> because you end up running a lot more code, and the bug triggers a
> lot faster.
> I tried to pinpoint the exact location of the problem, but no luck.

A gdb backtrace from a crash would help a lot in tracking down the bug.

Certainly the busy loop around the pulse is bad.  Looking at the
code, I imagine that it would be reasonable to do a SendReceive
(NULL,true) if the pulse deadline has not yet arrived.  That should
block for ~50-100ms until an SIP is received, which will get rid of
the busy loop.  The disadvantage is slight additional latency on
processing commands from subscribed clients, but that should not be a
serious issue.

        brian.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Playerstage-users mailing list
Playerstage-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/playerstage-users


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Playerstage-users mailing list
Playerstage-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/playerstage-users





--
This email is intended for the addressee only and may contain privileged and/or confidential information