Thank you for your report. I have fixed a number of memory leaks in gnucash 3.3 that may have been at least partly responsible for your crash.

Can you rerun your experiment with this version ?

If you can still crash it, please attach a gdb back trace and the contents of the gnucash trace file. Thank you.

Recently built version 3.3 (on a Debian 9 system, 8GB Ram, I5 processor) & tried importing a csv file with 1739 rows but had the same problem - an immediate crash on clicking 'OK'. When I reduced the csv file to 1073 rows it worked fine. Would be glad to send trace files if I knew where to find them...

@Poker The procedure to generate a gdb stack trace is documented here:
https://wiki.gnucash.org/wiki/Stack_Trace#Linux

In addition, after the successful csv import of 1073 rows, did you run a second csv file import with the remaining 666 rows ? And how did that work out ?

Importing the remaining rows was successful, so the issue appears to be the length of the csv file, not its contents. Here is the gdb gnucash and bt result when attempting to reimport my 1739-row csv file:

GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from gnucash...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/local/bin/gnucash 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffdda35700 (LWP 17893)]
[New Thread 0x7fffdc8f2700 (LWP 17894)]
[New Thread 0x7fffd7fff700 (LWP 17895)]
[New Thread 0x7fffce50c700 (LWP 17896)]
[New Thread 0x7fffcd091700 (LWP 17898)]
[New Thread 0x7fffcc890700 (LWP 17899)]
[New Thread 0x7fffbffff700 (LWP 17900)]
[New Thread 0x7fffbf7fe700 (LWP 17901)]
[New Thread 0x7fffbeffd700 (LWP 17902)]
[Thread 0x7fffcd091700 (LWP 17898) exited]
[New Thread 0x7fffcd091700 (LWP 17904)]
[Thread 0x7fffcd091700 (LWP 17904) exited]
[New Thread 0x7fffcd091700 (LWP 17905)]
[New Thread 0x7fff7c2ff700 (LWP 17906)]
[New Thread 0x7fff7b8ff700 (LWP 17909)]
[New Thread 0x7fff7b0fe700 (LWP 17912)]
[New Thread 0x7fff7a8fd700 (LWP 17913)]
[New Thread 0x7fff7a0fc700 (LWP 17924)]
[Thread 0x7fffcc890700 (LWP 17899) exited]
[Thread 0x7fff7a0fc700 (LWP 17924) exited]
[Thread 0x7fff7a8fd700 (LWP 17913) exited]
[New Thread 0x7fff7a8fd700 (LWP 17969)]
[New Thread 0x7fff7a0fc700 (LWP 17970)]
[New Thread 0x7fffcc890700 (LWP 17971)]
[Thread 0x7fff7a0fc700 (LWP 17970) exited]
[Thread 0x7fff7a8fd700 (LWP 17969) exited]
[New Thread 0x7fff7a8fd700 (LWP 17976)]
[Thread 0x7fff7a8fd700 (LWP 17976) exited]
[New Thread 0x7fff7a8fd700 (LWP 17977)]

(gnucash:17888): Gtk-WARNING **: Allocating size to GncMainWindow 0x555555b4e2d0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?
[Thread 0x7fff7a8fd700 (LWP 17977) exited]
[Thread 0x7fffcc890700 (LWP 17971) exited]
[New Thread 0x7fffcc890700 (LWP 17985)]
[New Thread 0x7fff7a8fd700 (LWP 17986)]
[New Thread 0x7fff7a0fc700 (LWP 17987)]
[Thread 0x7fff7a8fd700 (LWP 17986) exited]
[Thread 0x7fff7a0fc700 (LWP 17987) exited]
[New Thread 0x7fff7a0fc700 (LWP 17990)]
[Thread 0x7fffcc890700 (LWP 17985) exited]
[New Thread 0x7fffcc890700 (LWP 17991)]
[Thread 0x7fffcc890700 (LWP 17991) exited]
[Thread 0x7fff7a0fc700 (LWP 17990) exited]
[New Thread 0x7fff7a0fc700 (LWP 18005)]
[New Thread 0x7fffcc890700 (LWP 18006)]
[Thread 0x7fff7a0fc700 (LWP 18005) exited]

(gnucash:17888): Gdk-ERROR **: The program 'gnucash' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
  (Details: serial 161555 error_code 11 request_code 130 (MIT-SHM) minor_code 5)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

Thread 1 "gnucash" received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffff7178261 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0

(gdb) bt
#0  0x00007ffff7178261 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#1  0x00007ffff717a9a1 in g_log_writer_default () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007ffff7178dfc in g_log_structured_array () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007ffff71790f9 in g_log_structured () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x00007ffff657b80e in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#5  0x00007ffff6588b53 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#6  0x00007fffeb9b723d in _XError () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#7  0x00007fffeb9b4167 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#8  0x00007fffeb9b4225 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#9  0x00007fffeb9b5138 in _XReply () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#10 0x00007fffeb766054 in XIGetClientPointer () from /usr/lib/x86_64-linux-gnu/libXi.so.6
#11 0x00007ffff657d87e in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#12 0x00007ffff6b4e27d in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#13 0x00007ffff6b4e7ff in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#14 0x00007ffff65466e8 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#15 0x00007ffff7173123 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#16 0x00007ffff71726aa in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#17 0x00007ffff7172a60 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#18 0x00007ffff7172d82 in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#19 0x00007ffff6a3fd55 in gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#20 0x00007ffff0334b33 in gnc_ui_start_event_loop () from /usr/local/lib/gnucash/libgncmod-gnome-utils.so
#21 0x000055555555a3b9 in inner_main ()
#22 0x00007ffff7756dd3 in ?? () from /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
#23 0x00007ffff7722adc in ?? () from /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
#24 0x00007ffff77d2e36 in ?? () from /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
#25 0x00007ffff77a4ca0 in ?? () from /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
#26 0x00007ffff77dd4f3 in ?? () from /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
#27 0x00007ffff77fdf08 in ?? () from /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
#28 0x00007ffff772d5ab in scm_call_4 () from /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
#29 0x00007ffff77d2c8c in scm_catch_with_pre_unwind_handler () from /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
#30 0x00007ffff77d2f0e in scm_c_catch () from /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
#31 0x00007ffff772292b in ?? () from /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
#32 0x00007ffff7722bf4 in scm_c_with_continuation_barrier () from /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
#33 0x00007ffff77cfbea in ?? () from /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
#34 0x00007ffff74573c2 in GC_call_with_stack_base () from /usr/lib/x86_64-linux-gnu/libgc.so.1
#35 0x00007ffff77cfcd3 in ?? () from /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
#36 0x00007ffff77cfd13 in scm_with_guile () from /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
#37 0x00007ffff7756d64 in scm_boot_guile () from /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
#38 0x000055555555a8a7 in main ()
(gdb)

Sorry for the long delay.

The gdb run does indeed suggest some resource allocation error. Unfortunately it doesn't hint at where exactly it goes wrong.

There is a hint to run this experiment with environment variable GDK_SYNCHRONIZE set (I presume to something like 1 or TRUE). That way the program should break with a more meaningful stacktrace.

For the record I can't reproduce this on the current maint branch (soon to become gnucash 3.6).

That's with a test file containing about 5600 lines on my Fedora system with 16Gb of RAM. It does take a long time to complete, but it does without crashing.

Note that it's a bit unclear to me where exactly it crashed as my current system doesn't have an Ok button in any of the screens of the assistant. Was that right after selecting the file to import ? Or later in the assistant?

> The error was 'BadAlloc (insufficient resources for operation)'.

That means an allocation request (C malloc function) failed. It happened to happen in libgdk-x11, but that's randomness: The most likely cause is available memory exhaustion. That's pretty uncommon in these days of many GB of memory, so another possibility is a bad region in RAM causing a hardware fault and a failed allocation.

That's probably not what afflicted the OP.