What were you doing when this happened?

Uhm, I'm not sure. I happened a few times, but it's not really reproducibile.
I got it again, by opening and closing the overview multiple times, then accessing a tile that was fully white.

I pushed a fix for a crasher that could be related (bug 683040). Could you see if you ever manage to reproduce this again?

Yes, reproduced again, on current master (3.5.90-87-g525ad1b)

New trace:

+ Trace 230777

So I did some rework in the code handling the thumbnails in the model that might have tackled this, but I have no certainty whatsoever. All I know is that I've been running ephy under gdb for a while now and I am unable to make it crash.

Of course if you have more precise instructions on how to reproduce it, that would really help.

And again and again! This time, either it fails before fully loading the session, or just going to the "Oops, this page might have crashed the browser" and clicking "reload again" triggers it.
Same trace.

Epiphany is 3.5.91.1-5-gb07db6a, WebKit is 69cc15fb104158eca60725b8f926fa984ddd6704.

Oh, and by the way, the problem now exists for application mode too. There, the browser crashes midway through the page load.

Interesting, I blew the thumbnails cache and the problem did not appear. I restarted epiphany and it promptly crashed, so the problem seems to be in the caching code.

*** Bug 683478 has been marked as a duplicate of this bug. ***

Priit bisected this and found that the first commit where this is reproducible is c02832ac1f68cbdcf3fe97348983a64455137d8e.

That commit has a bug on x86_64: it uses int for the mtime, but it registers it as long.
I changed the GType to int, and I hasn't crashed yet.

OK, that would actually make sense. Could you please submit your patch for others to try?

Created attachment 223666 [details] [review]
EphyOverviewStore: don't register the snapshot mtime as long

All code paths use int, and this breaks on architechtures where
long is not the same as int (such as x86_64).

hm, I was thinking, isn't time_t supposed to be int64? I wonder if the proper fix shouldn't be the other way around (using long everywhere).

Isn't there similar issue with EPHY_OVERVIEW_STORE_LAST_VISIT ?

Patch works great!

(In reply to comment #13)
> Created an attachment (id=223666) [details] [review]
> EphyOverviewStore: don't register the snapshot mtime as long
> 
> All code paths use int, and this breaks on architechtures where
> long is not the same as int (such as x86_64).

Sorry if I'm dense, but can you explain why exactly this breaks in x86_64?

(In reply to comment #15)
> Isn't there similar issue with EPHY_OVERVIEW_STORE_LAST_VISIT ?

Yes. This might work because we're not really using that column right now.

About the patch, I am unsure that using int is the right thing to do. As far as
I understand time_t is not necessarily an int. I think that a better approach
would be to use time_t everywhere and a big enough type for the model
(G_TYPE_LONG seems right).

(In reply to comment #17)
> (In reply to comment #13)
> > Created an attachment (id=223666) [details] [review] [details] [review]
> > EphyOverviewStore: don't register the snapshot mtime as long
> > 
> > All code paths use int, and this breaks on architechtures where
> > long is not the same as int (such as x86_64).
> 
> Sorry if I'm dense, but can you explain why exactly this breaks in x86_64?

GtkTreeModel/GtkListStore uses varargs, and they depend on the length on the argument. If a column is typed G_TYPE_LONG, on set 64 bits of argument (or one full register, in x86_64) are read, while on get, the pointer is expected to hold 64 bits. On the other hand, the default argument promotions only go up to int, so undefined data read and/or stack corruption can happen on set. Worse, and probably the cause of this bug, on get it's possible that another adjacent variable is overwritten.

commit 8431cabd4d8f72dfaadbe64adf9f8dc89a26ae62
Author: Giovanni Campagna <gcampagna@src.gnome.org>
Date:   Thu Sep 6 17:40:51 2012 +0200

    EphyOverviewStore: don't register the snapshot mtime as long
    
    All code paths use int, and this breaks on architechtures where
    long is not the same as int (such as x86_64).
    
    https://bugzilla.gnome.org/show_bug.cgi?id=683029
    
    [Do the same for the visit time column]
    Signed-off-by: Claudio Saavedra <csaavedra@igalia.com>


Attachment 223666 [details] pushed as 8431cab - EphyOverviewStore: don't register the snapshot mtime as long

Make sure this gets into a 3.5.92 release, it's making ephy unusable for me.