the latest defaultfile branch

[Miika Turkia]

On Sun, Sep 16, 2012 at 11:57 AM, Dirk Hohndel <dirk at hohndel.org> wrote:
> Miika Turkia <miika.turkia at gmail.com> writes:
>
>> On Sun, Sep 16, 2012 at 2:33 AM, Dirk Hohndel <dirk at hohndel.org> wrote:
>>>
>>> This now implements what I think was the overall consensus:
>>>
>>> - Open opens just one file (and closes the currently open file / clears the dive list)
>>> - The open data file is named in the window title
>>> - Import moves back to the file menu
>>> - Import allows opening multiple files
>>
>>> Please test away and report crashes, bugs and any unexpected behavior.
>>
>> - start subsurface without files
>> - open a test dive
>> - go to open again, but hit cancel
>> => dive list emptied
>> * the state before going again to open is expected
>
> Yeah, I can totally see why it would do that. Let me adjust the ordering
> in the function a little bit to get this right. Should be easy enough.

Seems to be working now.

>> This one seems like the Ubuntu crash:
>> - ./subsurface /dives/test1.xml
>> - file -> open -> XML
>> - select any and hit open
>
> Is this with the latest git tree, posted about 5 hours ago?
> Is there a stack trace or just the "pthreads unexpected value" error?

Yep, with latest sources, the pthread thing. Following crash is with
fresh fetch:

GLib (gthread-posix.c): Unexpected error from C library during
'pthread_setspecific': Invalid argument.  Aborting.

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffe240c700 (LWP 2512)]
0x00007ffff5626445 in __GI_raise (sig=<optimised out>) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
64	../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007ffff5626445 in __GI_raise (sig=<optimised out>) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007ffff5629bab in __GI_abort () at abort.c:91
#2  0x00007ffff631b3e3 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007ffff63849a5 in g_private_set () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x00007ffff456614d in ?? () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#5  0x00007ffff636b248 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#6  0x00007ffff636a9e5 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#7  0x00007ffff5caee9a in start_thread (arg=0x7fffe240c700) at
pthread_create.c:308
#8  0x00007ffff56e24bd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#9  0x0000000000000000 in ?? ()

I did a small test earlier considering the trip date field. It really
seems weird and with this kind of behavior I would not be surprised if
the whole memory layout would be a corrupted. I added another fetch
for the DIVE_INDEX into the date_data_func for the existing
gtk_tree_model_get:

	gtk_tree_model_get(model, iter, DIVE_INDEX, &idx, DIVE_INDEX, &idx2,
DIVE_DATE, &val, -1);
	fprintf(stderr, "idx: %d idx2: %d\n", idx, idx2);

This resulted in following print:
$ ./subsurface dives/test[123].xml
idx: 0 idx2: -1
idx: 0 idx2: 2
idx: 0 idx2: 1
idx: 0 idx2: 0
idx: 0 idx2: -1
idx: 0 idx2: -1
idx: 0 idx2: 2
idx: 0 idx2: 2
idx: 0 idx2: 1
idx: 0 idx2: 1
idx: 0 idx2: 0
idx: 0 idx2: 0

I have no idea of what is going on but this seems quite wrong...

miika