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

GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=787439. Please continue processing the bug there and please update any external references or bookmarks.