On 19/04/2020 10:08 a.m., Stuart Henderson wrote:
On 2020/04/19 09:17, Steve Williams wrote:
I am missing something on building the Debug packages. I modified the
Makefile per your other email thread but there must be more magic as I don't
see any of the output pertaining to "Extracting debug info..."
As others mentioned, -current has some infrastructure to produce detached
symbols (and add links to the object so gdb can find them). That isn't
available in earlier releases but the standard old method of setting
DEBUG=-g in the environment is available:
make clean
make DEBUG=-g repackage (add e.g. MAKE_JOBS=4 to build on multiple cpus)
make reinstall
It is a bit disappointing that the newer version of freerdp needs
significant work to have it functional in OpenBSD. I had a look at the
Apple code for the timers... the whole timers file. Not very pleasant with
all the #ifdef's all over the place. I am sure greater minds than mine have
looked at what it would take to have it working in OpenBSD.
cheloha@ mentioned that he has done some work on posix timers for OpenBSD,
I'm not sure what state that is currently in, but it's probably more pleasant
and more useful to gone down that road than add special OpenBSD support to
freerdp..
I guess that leaves debugging the existing code. I started by comparing the
2.0rc1 /winpr/libwinpr/crt/alignment.c with the version in 2.0 and there
have been quite a few changes. It seems most of them are for clarity of
code, but hidden in the changes must be some alignment challenges. Lots of
math going on... and a few confusing comments.
For example:
/* alignment must be a power of 2 */
if (alignment % 2 == 1)
return NULL;
That's not a "power" of two, that's a "multiple" of 2. What did they really
mean?? I assume they meant multiple... but that's not what the code is
doing.
There are only 2 commits in that file between rc1 and 2.0; one is code
formatting, the other is this:
https://github.com/FreeRDP/FreeRDP/issues/2039 /
https://github.com/FreeRDP/FreeRDP/pull/4961
Perhaps it will fix the problem you're seeing. Please try building with the
attached file saved in /usr/ports/x11/freerdp/patches.
Hi,
Thanks very much for all the information. I'll have to spin up my old
desktop & upgrade it if I'm going to get serious about troubleshooting
this. My current box is an APU :).
Using DEBUG=-g, I complied a debugging library (OpenBSD 6.6) and was
able to get a meaningful stack trace. I then applied your patch and
recompiled and was getting a meaningful stack trace in the new code.
What is the "fastest" way to iterate troubleshooting in the "packages"
world.
Is it possible to make modifications to the code directly in the
/usr/ports/pobj/freerdp-2.0.0rc1 tree and somehow magically re-compile
starting there, rather than having to create a patch, make clean, etc?
Sorry for the newby questions..
Once I understand the build environment, I'll be fine working through
this...
And for reference, the code is blowing up on line 234
void _aligned_free(void* memblock)
{
WINPR_ALIGNED_MEM* pMem;
if (!memblock)
return;
pMem = WINPR_ALIGNED_MEM_STRUCT_FROM_PTR(memblock);
if (pMem->sig != WINPR_ALIGNED_MEM_SIGNATURE)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Core Dump -
{
WLog_ERR(TAG, "_aligned_free: memory block was not
allocated by _aligned_malloc!");
return;
}
free(pMem->base_addr);
}
#0 _aligned_free (memblock=0xdfdfdfdfdfdfdfdf) at
/usr/ports/pobj/freerdp-2.0.0rc1/freerdp-2.0.0-rc1/winpr/libwinpr/crt/alignment.c:234
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Wow, that memblock looks pretty suspicious!!
#1 0x0000047714e6a215 in Bitmap_Free (context=Variable "context" is not
available.
) at
/usr/ports/pobj/freerdp-2.0.0rc1/freerdp-2.0.0-rc1/libfreerdp/core/graphics.c:64
#2 0x0000047714e2a79d in gdi_bitmap_update (context=0x477c4c397f0,
bitmapUpdate=Variable "bitmapUpdate" is not available.
) at color.h:762
#3 0x0000047714e864c4 in fastpath_recv_update (fastpath=Variable
"fastpath" is not available.
) at stream.h:57
#4 0x0000047714e84a93 in fastpath_recv_updates (fastpath=Variable
"fastpath" is not available.
) at
/usr/ports/pobj/freerdp-2.0.0rc1/freerdp-2.0.0-rc1/libfreerdp/core/fastpath.c:538
#5 0x0000047714e80468 in rdp_recv_pdu (rdp=0x477663bf400,
s=0x476fb847000) at
/usr/ports/pobj/freerdp-2.0.0rc1/freerdp-2.0.0-rc1/libfreerdp/core/rdp.c:1294
#6 0x0000047714e7fa44 in rdp_recv_callback (transport=Variable
"transport" is not available.
) at
/usr/ports/pobj/freerdp-2.0.0rc1/freerdp-2.0.0-rc1/libfreerdp/core/rdp.c:1448
#7 0x0000047714e88e63 in transport_check_fds (transport=0x4772b5e4a00)
at
/usr/ports/pobj/freerdp-2.0.0rc1/freerdp-2.0.0-rc1/libfreerdp/core/transport.c:1035
#8 0x0000047714e80c71 in rdp_check_fds (rdp=0x477663bf400) at
/usr/ports/pobj/freerdp-2.0.0rc1/freerdp-2.0.0-rc1/libfreerdp/core/rdp.c:1507
#9 0x0000047714e690a8 in freerdp_check_fds (instance=0x47729c05000) at
/usr/ports/pobj/freerdp-2.0.0rc1/freerdp-2.0.0-rc1/libfreerdp/core/freerdp.c:316
#10 0x0000047714e69341 in freerdp_check_event_handles
(context=0x477c4c397f0) at
/usr/ports/pobj/freerdp-2.0.0rc1/freerdp-2.0.0-rc1/libfreerdp/core/freerdp.c:365
#11 0x000004779606d644 in guac_rdp_handle_connection () from
/usr/local/lib/libguac-client-rdp.so.0.0
#12 0x000004779606da11 in guac_rdp_client_thread () from
/usr/local/lib/libguac-client-rdp.so.0.0
#13 0x000004771814cdf1 in _rthread_start (v=Variable "v" is not available.
) at /usr/src/lib/librthread/rthread.c:96
#14 0x0000047780d3cc48 in __tfork_thread () at
/usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:77
#15 0x0000000000000000 in ?? ()
Thanks,
Steve W.
