In Chrome, stack information is slightly different if an eval() statement is part of the stack in an attempt to pin down what line of the eval() is causing the issue. The Chrome bug report that led to this logging is here: https://code.google.com/p/v8/issues/detail?id=1914

Basically, the line in the trace ends up looking something like this:
at fn (eval at (https://www.mydomain.com:1:100), :2:20)

The StackFrame that gets returned from the parse then has as the filename and the line/column numbers of the anonymous reporting. If you are using the full stacktrace.js fromError call and thus get stacktrace-gps along for the ride, this causes stacktrace-gps to try to download https://www.mydomain.com/ <anonymous> (I'm not sure how to format this properly; there shouldn't be the space after the slash) to look for source maps. Of course, that will never be a useful case; the best you can hope for is a 404, and I'm not really sure whether the code can recover from that situation.

Now, I recognize that there is some potential debugging/logging value in what Chrome has output for the eval()-specific information, so it may be worth adding some method of preserving that for interested parties. But in the short term, it really seems like the filename/line/column returned in the StackFrame in this situation should report the information in the middle set of parentheses. At the very least, that would keep stacktrace-gps from making a useless HTTP call and even potentially blowing up.