On 2020/04/19 12:25, Steve Williams wrote:
> 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?
Yes, make rebuild / make fake / make repackage (with DEBUG=-g set for
rebuild/fake; as well as being passed to cc it also controls stripping
in "fake").
Ports also has support for ccache which can save rebuild time while
working on things. Not so much needed for this case, but if you need to
clean and do a whole rebuild (changing configure options, etc) it can
be quite helpful. See USE_CCACHE in bsd.port.mk(5).
> Sorry for the newby questions..
No need to apologise, these are questions which are not really
discoverable in docs. DEBUG is mentioned in mk.conf(5) but it's not
at all obvious that it will apply to ports too.
> 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!!
Consult malloc(3) on the subject of 0xdf.
