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 currently missing hardware rendering. Since this unimplemented rendering
was now chosen by default, it crashed. When I added the option, I tested
using the option and explicitly choosing software rendering, which is why I
didn't notice before. It's fixed on my github fork now, sorry about that.

On Sun, Jun 5, 2011 at 3:08 PM, Marc-André Moreau <
marcandre.mor...@gmail.com> wrote:

> 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
> negotiated resolution and color depth then. The problem is that there is a
> race condition between having the post_connect method called and the first
> graphical messages received. If one is received too fast before the DirectFB
> structures are properly initialized, then it may crash, like it currently is
> the case. I don't know why it worked before then... it's weird that we
> notice it now.
>
>
> On Sun, Jun 5, 2011 at 2:58 PM, Marc-André Moreau <
> marcandre.mor...@gmail.com> wrote:
>
>> 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
>> registered, so the stubs get them.
>>
>>
>> On Sun, Jun 5, 2011 at 2:54 PM, Marc-André Moreau <
>> marcandre.mor...@gmail.com> wrote:
>>
>>> 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.
>>> Definitely, something is fishy around the cache
>>>
>>>
>>> On Sun, Jun 5, 2011 at 1:16 PM, Gerry Reno <gr...@verizon.net> wrote:
>>>
>>>> Here's what I see in the debugger:
>>>>
>>>>    0000 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                                           ..
>>>>    0000 1a 00 [New Thread 0x7ffff2268910 (LWP 23131)]
>>>>
>>>>    Program received signal SIGSEGV, Segmentation fault.
>>>>    [Switching to Thread 0x7ffff2268910 (LWP 23131)]
>>>>    0x0000000000402585 in l_ui_create_cursor (inst=<value optimized
>>>>    out>, x=15, y=16, width=32, height=32,
>>>>        andmask=<value optimized out>, xormask=0x7fffec0117af "",
>>>>    bpp=24) at dfb_win.c:320
>>>>    320        ret = dfbi->dfb->CreateSurface(dfbi->dfb, &dsc,
>>>>    &cursor->surface);
>>>>    Missing separate debuginfos, use: debuginfo-install
>>>>    directfb-1.2.9-2.fc11.x86_64 libXext-1.0.99.1-2.fc11.x86_64
>>>>    libXinerama-1.0.3-4.fc11.x86_64 libgcc-4.4.0-4.x86_64
>>>>    (gdb) quit
>>>>
>>>> And here's what I see when I grep for CreateSurface:
>>>>
>>>>    $ grep -RHn CreateSurface *
>>>>    Binary file dfb/dfbfreerdp-dfb_win.o matches
>>>>    Binary file dfb/.libs/lt-dfbfreerdp matches
>>>>    Binary file dfb/.libs/dfbfreerdp matches
>>>>    Binary file dfb/dfbfreerdp-dfb_event.o matches
>>>>    dfb/dfb_win.c:320:    ret = dfbi->dfb->CreateSurface(dfbi->dfb,
>>>>    &dsc, &cursor->surface);
>>>>    dfb/dfb_win.c:529:        dfbi->err =
>>>>    dfbi->dfb->CreateSurface(dfbi->dfb, &(dfbi->dsc), &(dfbi->primary));
>>>>    dfb/dfb_win.c:554:        dfbi->dfb->CreateSurface(dfbi->dfb,
>>>>    &(dfbi->dsc), &(dfbi->surface));
>>>>    sdl/sdl_win.c:198:    ret = dfbi->dfb->CreateSurface(dfbi->dfb,
>>>>    &dsc, &cursor->surface);
>>>>    $
>>>>
>>>> Where is it defined?
>>>>
>>>>
>>>> Gerry
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 06/05/2011 01:09 PM, Marc-André Moreau wrote:
>>>> > 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 <gr...@verizon.net
>>>> > <mailto:gr...@verizon.net>> wrote:
>>>> >
>>>> >     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/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 NLA
>>>> >     >>
>>>> >     >> To which version of the server are you connecting?
>>>> >     >>
>>>> >     >> On Sat, Jun 4, 2011 at 10:41 PM, Gerry Reno <gr...@verizon.net
>>>> >     <mailto:gr...@verizon.net>
>>>> >     >> <mailto:gr...@verizon.net <mailto:gr...@verizon.net>>> wrote:
>>>> >     >>
>>>> >     >>     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 24bpp)
>>>> >     >>     >
>>>> >     >>     > On Sat, Jun 4, 2011 at 10:35 PM, Gerry Reno
>>>> >     <gr...@verizon.net <mailto:gr...@verizon.net>
>>>> >     >>     <mailto:gr...@verizon.net <mailto:gr...@verizon.net>>
>>>> >     >>     > <mailto:gr...@verizon.net <mailto:gr...@verizon.net>
>>>> >     <mailto:gr...@verizon.net <mailto:gr...@verizon.net>>>> wrote:
>>>> >     >>     >
>>>> >     >>     >
>>>> >     >>     >     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
>>>> >     <http://192.168.2.49:3389>
>>>> >     >>     <http://192.168.2.49:3389> <http://192.168.2.49:3389>
>>>> >     >>     >        run_dfbfreerdp:
>>>> >     >>     >        keyboard_layout: 0
>>>> >     >>     >        connecting to 192.168.2.49:3389
>>>> >     <http://192.168.2.49:3389>
>>>> >     >>     <http://192.168.2.49:3389> <http://192.168.2.49:3389>
>>>> >     >>     >        connecting to 192.168.2.49:3389
>>>> >     <http://192.168.2.49:3389>
>>>> >     >>     <http://192.168.2.49:3389> <http://192.168.2.49:3389>
>>>> >     >>     >        connecting to 192.168.2.49:3389
>>>> >     <http://192.168.2.49:3389>
>>>> >     >>     <http://192.168.2.49:3389> <http://192.168.2.49:3389>
>>>> >     >>     >        Standard RDP encryption negotiated
>>>> >     >>     >        ui_error: ERROR: get bitmap 0:0
>>>> >     >>     >        ui_error: ERROR: get font 6:0
>>>> >     >>     >        ui_error: ERROR: get font 6:0
>>>> >     >>     >        ui_error: ERROR: get font 6:0
>>>> >     >>     >
>>>> >     >>     >     Do I need to configure something?
>>>> >     >>     >
>>>> >     >>     >
>>>> >     >>     >     Gerry
>>>> >     >>     >
>>>> >     >>     >
>>>> >     >>     >
>>>> >     >>     >
>>>> >     >>     >
>>>> >     >>
>>>> >
>>>> ------------------------------------------------------------------------------
>>>> >     >>     >     Simplify data backup and recovery for your virtual
>>>> >     environment
>>>> >     >>     >     with vRanger.
>>>> >     >>     >     Installation's a snap, and flexible recovery options
>>>> >     mean your
>>>> >     >>     >     data is safe,
>>>> >     >>     >     secure and there when you need it. Discover what all
>>>> the
>>>> >     >>     >     cheering's about.
>>>> >     >>     >     Get your free trial download today.
>>>> >     >>     >     http://p.sf.net/sfu/quest-dev2dev2
>>>> >     >>     >     _______________________________________________
>>>> >     >>     >     Freerdp-devel mailing list
>>>> >     >>     >     Freerdp-devel@lists.sourceforge.net
>>>> >     <mailto:Freerdp-devel@lists.sourceforge.net>
>>>> >     >>     <mailto:Freerdp-devel@lists.sourceforge.net
>>>> >     <mailto:Freerdp-devel@lists.sourceforge.net>>
>>>> >     >>     >     <mailto:Freerdp-devel@lists.sourceforge.net
>>>> >     <mailto:Freerdp-devel@lists.sourceforge.net>
>>>> >     >>     <mailto:Freerdp-devel@lists.sourceforge.net
>>>> >     <mailto:Freerdp-devel@lists.sourceforge.net>>>
>>>> >     >>     >
>>>> >     https://lists.sourceforge.net/lists/listinfo/freerdp-devel
>>>> >     >>     >
>>>> >     >>     >
>>>> >     >>
>>>> >     >>
>>>> >     >>
>>>> >     >
>>>> >     >
>>>> >     >
>>>> >
>>>> ------------------------------------------------------------------------------
>>>> >     > Simplify data backup and recovery for your virtual environment
>>>> >     with vRanger.
>>>> >     > Installation's a snap, and flexible recovery options mean your
>>>> >     data is safe,
>>>> >     > secure and there when you need it. Discover what all the
>>>> >     cheering's about.
>>>> >     > Get your free trial download today.
>>>> >     > http://p.sf.net/sfu/quest-dev2dev2
>>>> >     > _______________________________________________
>>>> >     > Freerdp-devel mailing list
>>>> >     > Freerdp-devel@lists.sourceforge.net
>>>> >     <mailto:Freerdp-devel@lists.sourceforge.net>
>>>> >     > https://lists.sourceforge.net/lists/listinfo/freerdp-devel
>>>> >     >
>>>> >     >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> ------------------------------------------------------------------------------
>>>> >     Simplify data backup and recovery for your virtual environment
>>>> >     with vRanger.
>>>> >     Installation's a snap, and flexible recovery options mean your
>>>> >     data is safe,
>>>> >     secure and there when you need it. Discover what all the
>>>> >     cheering's about.
>>>> >     Get your free trial download today.
>>>> >     http://p.sf.net/sfu/quest-dev2dev2
>>>> >     _______________________________________________
>>>> >     Freerdp-devel mailing list
>>>> >     Freerdp-devel@lists.sourceforge.net
>>>> >     <mailto:Freerdp-devel@lists.sourceforge.net>
>>>> >     https://lists.sourceforge.net/lists/listinfo/freerdp-devel
>>>> >
>>>> >
>>>>
>>>>
>>>
>>
>
------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today. 
http://p.sf.net/sfu/quest-dev2dev2 
_______________________________________________
Freerdp-devel mailing list
Freerdp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freerdp-devel

Reply via email to