What happens when I hover over a link in Chrome?

The crash is due to a recently discovered bug in Chrome - and other WebKit browsers(!)* - specifically related to either %%30%30, %0%30 or %%300 as part of the URL, which internally all end up representing the same symbol: null. You can read more about the bug here.

It's not a bug that affect most links, so you don't generally have to worry about hovering over links.

Notes:
* Other WebKit browsers include Safari, Opera, Steam Browser, Midori, S60 (Symbian), Blackberry Browser and Playstation 3's browser - but not Firefox, Internet Explorer or Edge.

Edit: This bug has now been fixed in Chrome 45.0.2454.101 as Deltik points out.

More about what happens

The problem is related to the URL canonicalizer, which runs as soon as you hover over a link - possibly for displaying the link in the status bar of the browser, and for prefetching the webpage so it loads faster once clicked.

As for the role of the URL canonicalizer:
When a URL is written in HTML, it may be written in a form such as /home or ../../home, but browsers need to translate this URL to something with a protocol and a domain too, like http://superuser.com/home. Furthermore the URL may contain URL Escapes that need to be translated, and these escapes are percent encoded, like %%30%30. (A more exhaustive list of URL escapes here).
The functionality handling this URL translation is what's ending up crashing, because it receives input the developers did not expect/handle.

Here's a summary of the code change that fixed the problem:

Correctly handle problematic nested escapes in URL paths.

Specifically, if unescaping in the input leads to the output URL containing a new escaped sequence, e.g. converting the input "%%30%30" to "%00", escape the leading '%' as "%25" to ensure the output sequence is not treated as a new valid escape sequence.

This ensures that canonicalizing the same URL a second time won't make changes to it, which is important for avoiding crashes and other bugs in a variety of places in both debug and release builds.

As Fabio Turati says,

When you hover over a link, Chrome displays it in the lower left corner. This requires some processing, including the "translation" of specially encoded characters.

However, from your post and comment I think you are more concerned about whether Chrome connects to the link in the background. It does, so do other modern browsers(Firefox, Opera). You may want to disable prefetching in Chrome's preferences, or install uBlock Origin to get more privacy settings.

I wanted to give some further clarification on what exactly happens here.

Basically, %30 is an URL-encoded 0, and %00 is a URL-encoded NULL (which is displayed in binary as 0000 0000). So if you have a URL that has a nested encoded character that will decode to NULL, the bug occurs.

Chrome does the following when canonicalizing a URL (source:https://code.google.com/p/chromium/issues/detail?id=533361#c13) :

• An input string "http: //a.com/%%30%30" is unescaped to "http://a.com/%00" and considered a valid GURL.
• This GURL is eventually sent to GURLToDatabaseURL(), which calls ReplaceComponents() on it to strip the username and password.
• ReplaceComponents() re-canonicalizes the URL.
• Canonicalization of the path hits the "%00" sequence, unescapes, sees this is a 0 char which is invalid in URLs, leaves it escaped, but marks the resulting URL as invalid.
• Once we return back to GURLToDatabaseURL(), it calls .spec() on the new URL, expecting it to be valid, since the input URL was guaranteed to be valid and we merely removed the username and password. This DCHECKs.

So the URL is first considered valid, but after removing certain private data, it's invalidated. However, after that data is removed, the function that called that particular code expects a valid URL.

Part of the reason why this URL is considered invalid is because NULL is used in a number of older software and languages to indicate the end of a string (because it's basically 8 zeroes in a line, which is easy to detect for a computer).