There are many LOG_DEBUG statements that seem to be in sesman that I
suspect would be useful for learning how the connections are set up and
configured. The problem may very well not be in sesman, but I won't know
for sure unless I can figure out how to enable #define DEBUG in it and see
it outputting verbose information in the logs. Right now, I need a way to
just get access to everything the system is doing, which also includes
things like building with -Og so I that variable values aren't optimized
out.

The bug, in more simple terms is:

1. Boot XRDP/connect correctly
2. Begin playing a youtube video on the remote session (this is more to
keep the session continually re-broadcasting video data than a video
specifically)
3. Kill the connection between the client/server abnormally (turn off
wireless card, pull the network cable, kill the VPN, etc).
4. Reconnect
5. Remote session is frozen at log-in with that particular stack trace.

So what I'm suspecting is that the connections that sesman is creating is
re-using sockets that have terminated abnormally and have been reallocated
by the linux kernel, but that either XRDP or sesman has not properly freed,
creating a deadlock blocking situation, but I need more information about
what both XRDP and sesman is up to in order to discern this.

-Christopher


On Tue, Oct 22, 2013 at 7:57 PM, Jay Sorg <jay.s...@gmail.com> wrote:

> > I'm still trying to track down the re-connection bug that is happening in
> > XRDP;
> >
> >
> http://xrdp-devel.766250.n3.nabble.com/XRDP-performance-under-heavy-packet-loss-10-20-td4025265.html
> >
> > And I want to follow the steps in here:
> >
> >
> http://www.xrdp.org/index.php?option=com_content&view=article&id=20:for-developers-only-x11rdp-chansrv-no-sesman&catid=2:documents&Itemid=7
> >
> > However, the instructions say "this works well for developing any
> component
> > in XRDP except sesman." Unfortunately, I'm pretty sure the bug is in
> sesman,
> > or at least, debugging sesman is a first step to getting to the bottom of
> > this issue... So, what is the ideal way to develop for sesman?
>
> Nexarian,
>
> Debugging sesman is possible.  I can do a document on it.
> I was looking at the stack trace and it does not look like a sesman issue.
> What makes you think it's sesman?
> Sesman pretty much just logs you in and starts process.
>
> Jay
>
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
_______________________________________________
xrdp-devel mailing list
xrdp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xrdp-devel

Reply via email to