Thanks for taking the time to report this bug.
This bug report isn't very useful because it doesn't describe the bug well. 
Can you, if possible, attach the file causing the crash?  This may help us
finding the cause of the bug.
This may be a Popple Bug (the backend Evince use for rendering PDF), could you
please supply the poppler version and
type? I have "poppler 0.4.2 (splash)". You can find it in the Help->About menu in
Evince.

On that line, I have
"Using poppler 0.4.2 (cairo)"

I'll try recompiling poppler with debugging symbols, and see where that leads.
Depending on my free time, I might be able to localize this crash myself.

I've found this crash to occur on multiple files, but I'll attach one that I
know exhibits this.

Here's a copy of what bug-buddy records when it crashes now that I've installed
unstripped versions of evince and libpoppler:
============================
Backtrace was generated from '/usr/bin/evince'

(no debugging symbols found)
Using host libthread_db library "/lib/tls/libthread_db.so.1".
(no debugging symbols found)
`system-supplied DSO at 0xffffe000' has disappeared; keeping its symbols.
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1228036416 (LWP 12415)]
[New Thread -1228170320 (LWP 12416)]
0xb7152c41 in waitpid () from /lib/tls/libc.so.6

+ Trace 63809

I'll attach this file (it's the same one as the last time) momentarily.

Created attachment 54116 [details]
The file I've most recently used to cause this crash.

I notice in the backtrace from Thread 1 (the last in the latter output), both
'begin' and 'p' appear to be NULL pointers. 

Looking at line 3441 in TextOutputDev.cc in poppler, p is dereferenced (as
p->next) without any test for p != NULL. I can't tell by inspection whether p is
supposed to be a pointer to an element in a linked list defined by begin, but
that's what it looks like. Since begin is NULL at that point, and p was just
initialized to begin, p->next is a NULL pointer dereference. 

I'll try to chase down how this got there through the call stack soon. Looking
slightly earlier in the code, it looks like lines may have been NULL (though
that seems odd, assuming lines is the list of lines in the document). This code
looks fairly easy to follow, so I'll see what some debugging turns up.

Here's a summary of what I've found in gdb. Basically, somehow, the loop along
the lines linked list is setting end to the element before begin, as seen below,
making the second loop starting from p=begin dereference the NULL pointer at the
end of the lines list before reaching end:

(gdb) print begin
$13 = (TextLine *) 0x8266b78
(gdb) print end
$14 = (TextLine *) 0x83456f8
(gdb) print lines
$15 = (TextLine *) 0x829c760
(gdb) print lines->next
$16 = (TextLine *) 0x82a1bc8
(gdb) print lines->next->next
$17 = (TextLine *) 0x83854e0
(gdb) print lines->next->next->next
$18 = (TextLine *) 0x839aef8
(gdb) print lines->next->next->next->next
$19 = (TextLine *) 0x8308d98
(gdb) print lines->next->next->next->next->next
$20 = (TextLine *) 0x83456f8                 <= this is end
(gdb) print lines->next->next->next->next->next->next
$21 = (TextLine *) 0x8266b78                 <= this is begin
(gdb) print lines->next->next->next->next->next->next->next
$22 = (TextLine *) 0x0                       <= this is the NULL pointer :-)

Looking at the code, the only place anything other than NULL is assigned to end
(which would prevent this because of the p != end test at the top of the loop)
is at line 3424 of TextOutputDev.cc of poppler. I'll try to muster the willpower
to examine all of the lines and so forth to divine what's up with the selection
coordinates that's causing this.

Should this bug be moved over to poppler, or is it more likely that there's an
error in how TextBlock::visitSelection is being called or what it's being called on?

For completeness, here's the backtrace from this run:

+ Trace 63810

Ah, looking about now, this seems to be a duplicate of bug #315552, which
clearly links to the poppler bug #4402
<https://bugs.freedesktop.org/show_bug.cgi?id=4402> that I found searching there.

I'll leave comments in those as well, to see that this bug report gets cleaned up.

Surely, thanks for reporting and tesing. Let me continue my comment on poppler
bug instead.

*** This bug has been marked as a duplicate of 315552 ***