I'm not able to reproduce this on a current unstable branch and the stack trace that you provided isn't consistent with the reported problem. The actual crash is from attempting to dereference an invalid but non-NULL GncCommodity*. I don't see a way for the Transfer Dialog to produce one of those.

So please test again with a build of the current unstable branch from git. If you can reproduce it try to track back where the invalid GncCommodity* is coming from.

Able to reproduce on branch master, commit id
435b0ace18d5d7a89b1fef0449b5861474d5910a.

It does not happen every time, you may need to repeat reproduction
steps several (at least 3 or more) times. I find that it happens more
often if I do the following:

_Modified Reproduction_

1. In the Account Tree: Open Actions > Transfer...
2. In the right hand account list, select a different account
3. In the Date input field, remove all input (so it is blank)
4. Press Esc

I will attach two different stack traces I got from reproducing this,
but they seem to be symptoms of the same underlying cause.

In gnome-utils/dialog-transfer.c:312
---
    if (!GNC_IS_COMMODITY (xferData->from_commodity) ||
        !GNC_IS_COMMODITY (xferData->to_commodity)) return;
---

Either the from_commodity or to_commodity has a value it doesn't like.

Also in gnome-utils/dialog-transfer.c:1689
---
    if (response != GTK_RESPONSE_OK)
    {
        gnc_close_gui_component_by_data (DIALOG_TRANSFER_CM_CLASS, xferData);
        LEAVE("cancel, etc.");
        return;
    }
---

Comparing the value of xferData->to_commodity and xferData->from_commodity
before and after the call to gnc_close_gui_component_by_data, they seem
to get weird values.

For example, running with gdb, before:
---
(gdb) print *xferData->to_commodity
$80 = {inst = {object = {g_type_instance = {g_class = 0x40eafe0}, ref_count = 1, qdata = 0x0}, e_type = 0x40eb5f0 "Commodity", kvp_data = 0x4180180}}
(gdb) print *xferData->from_commodity
$81 = {inst = {object = {g_type_instance = {g_class = 0x40eafe0}, ref_count = 1, qdata = 0x0}, e_type = 0x40eb5f0 "Commodity", kvp_data = 0x4180180}}
---

After:
---
(gdb) print *xferData->to_commodity
$82 = {inst = {object = {g_type_instance = {g_class = 0x50f1570}, ref_count = 1480938591, qdata = 0x52afc98}, e_type = 0x411 <error: Cannot access memory at address 0x411>, kvp_data = 0x1d02e00}}
(gdb) print *xferData->from_commodity
$83 = {inst = {object = {g_type_instance = {g_class = 0x5180c30}, ref_count = 83302088, qdata = 0x4fc1d68}, e_type = 0x4fc1cc8 "fourth", kvp_data = 0x4fc1bb8}}
---

After which I get the segfault. However, the segfault does not always
happen when to_commodity and from_commodity are changed.

My speculation is that closing the dialog with the date field empty
causes gnc_close_gui_component_by_data to delete xferData while
gnc_xfer_date_changed_cb attempts to update it. If there is a race
here then it might explain why the segfault is intermittent.

But I have yet to find any conclusive evidence of this.

Might also be a bug in my GTK/Gnome library. I found this
https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1438014 which
sounds somewhat similar, but not sure.

Versions if it is relevant:
libgtk2.0-0: 2.24.25-3+deb8u2
libglib2.0-0: 2.42.1-1+b1

Created attachment 372480 [details]
stack trace 1

Created attachment 372481 [details]
stack trace 2

I can't reproduce this either on my Fedora linux system, using the current maint branch (3.2+). However reading your stack traces I can imagine where it goes wrong and it would indeed be a race condition.

Hitting escape will trigger the destruction of the dialog. This in turn will trigger a focus-out event on the date entry. And that will then trigger another price update callback. Depending on how far the destruction of the dialog's data structure had proceeded this may cause an attempt to read a no longer valid commodity. All theoretical as I can't reproduce.

However I have added code that removes the price update trigger on the  date entry's focus-out event before starting the destruction of the dialog. That should prevent this command chain leading to this potential crash.

Can you build the current maint branch and report back if you can still reproduce this issue now ?

I was not able to reproduce on maint branch:
Version: 3.3
Build ID: git 3.3-132-gde6c173+ (2018-11-28)

Debian 8.11 Linux t60 3.16.0-7-amd64 #1 SMP Debian 3.16.59-1 (2018-10-03) x86_64 GNU/Linux

According to gdb, gnc_xfer_date_changed_cb() never got called when pressing Esc.

I also tested a bit around the other fields in the dialog to see if a similar bug affected them.