Verified. SIGSEGV is gone.
Gerry
On 06/05/2011 03:28 PM, Gerry Reno wrote:
> Great!
>
> Can you do a pull request and merge it into the tree? Or do you need to
> run some tests?
>
>
> Gerry
>
>
>
> On 06/05/2011 03:23 PM, Marc-André Moreau wrote:
>
>> I got it fixed. it turns out it was a r
Great!
Can you do a pull request and merge it into the tree? Or do you need to
run some tests?
Gerry
On 06/05/2011 03:23 PM, Marc-André Moreau wrote:
> I got it fixed. it turns out it was a really stupid mistake... when I
> introduced the "--gdi" option to choose between hardware and softwar
If you want to avoid recompiling or using my branch, using --gdi sw should
make it work (the problem being that the default option is simply wrong). I
should remove the "hw" option from the help though, since it's not
implemented yet.
On Sun, Jun 5, 2011 at 3:23 PM, Marc-André Moreau <
marcandre.m
I got it fixed. it turns out it was a really stupid mistake... when I
introduced the "--gdi" option to choose between hardware and software GDI
rendering, I left the default option as hardware. This was meant to enable
an easy switch for developers to turn on hardware rendering and implement
the cu
So in the case of being on a gigabit LAN as we are here this might cause
the message to be processed before the DirectFB structures were
initialized is what you are saying?
Gerry
On 06/05/2011 03:08 PM, Marc-André Moreau wrote:
> Ok, registering the callbacks prior to connection does fix the f
Ok, registering the callbacks prior to connection does fix the font issue,
but not the cursor. He's my guess: the cursor callback, unlike the font
callback, requires DirectFB-specific structures to be initialized. I was
initializing DirectFB stuff after connection, since you only know about the
neg
got it I think, it has to be related to the two set of callbacks which were
recently introduced. by default, it registers the stubs, and then only
registers the real callbacks after connection. however, messages related to
the cache have the time to be received before the real callbacks are
registe
there appears to be an issue with the cache, for instance, cache_put_font
gets called before calls to cache_get_font for the same font, except that
cache_put_font was passed a NULL pointer, which is where there is an error
in cache_get_font... I guess similar issues happen with the cursor cache.
De
Here's what I see in the debugger:
22 00 17 00 ea 03 ea 03 01 00 00 01 14 00 1c 00 "...
0010 00 00 01 00 00 00 ec b7 eb 4d 00 00 00 00 00 00 .M..
0020 00 00 ..
1a 00 [New Thread 0x72268910 (LWP 23131)]
Hi Gerry,
Actually, now it crashes on me for all servers. I'll try to figure it out, I
think it might be related to the potential buffer overflow which is rampant
that affected only the windows port so far.
On Sun, Jun 5, 2011 at 9:01 AM, Gerry Reno wrote:
> Could you try connecting to Windows
Could you try connecting to Windows XP and see if you can reproduce the
problem?
I'm not making any progress here on solving this.
Gerry
On 06/04/2011 10:46 PM, Gerry Reno wrote:
> Right now I'm connecting to Windows XP. I don't have a server running
> at the moment.
>
> Gerry
>
>
>
> On 06/0
Right now I'm connecting to Windows XP. I don't have a server running
at the moment.
Gerry
On 06/04/2011 10:43 PM, Marc-André Moreau wrote:
> I just tried it myself, I can't reproduce the issue
>
> I tried with --sec rdp since you seem to be connecting to a server
> that doesn't support TLS or
I just tried it myself, I can't reproduce the issue
I tried with --sec rdp since you seem to be connecting to a server that
doesn't support TLS or NLA
To which version of the server are you connecting?
On Sat, Jun 4, 2011 at 10:41 PM, Gerry Reno wrote:
> No change. Both 16 and 32 produce the
No change. Both 16 and 32 produce the exact same error.
Gerry
On 06/04/2011 10:37 PM, Marc-André Moreau wrote:
> you're specifying 24bpp explicitely? that might actually cause
> problems, try either 32bpp or 16bpp and see if the problem still
> occurs (there is limited/untested support for 24b
you're specifying 24bpp explicitely? that might actually cause problems, try
either 32bpp or 16bpp and see if the problem still occurs (there is
limited/untested support for 24bpp)
On Sat, Jun 4, 2011 at 10:35 PM, Gerry Reno wrote:
>
> I am having a bitmap and font problem with latest code:
>
>
I am having a bitmap and font problem with latest code:
$ dfb/dfbfreerdp -a 24 192.168.2.49
starting thread 1 to 192.168.2.49:3389
run_dfbfreerdp:
keyboard_layout: 0
connecting to 192.168.2.49:3389
connecting to 192.168.2.49:3389
connecting to 192.168.2.49:3389
Sta
16 matches
Mail list logo
