The answer to this question involves a bit of background in how paging works. In modern operating systems applications do not access physical memory addresses but rather virtual memory addresses. The mapping between virtual and physical memory happens in chunks called pages. The page size depends on the hardware, the most common side is 4KB.
When a process is started most of the virtual memory address space is empty. Accessing it will cause a trap into the OS kernel, which may terminate the process and perhaps log the event.
As the process needs memory, it requests memory from the operating system one or more pages at a time.
The heartbleed bug would allow leaking up to 64KB of data. That means it can cross as much as 16 page boundaries (in other words it may span 17 pages). The first of those pages is where the legitimate data is stored, so that page is guaranteed to exist. But the following 16 pages of virtual address space may not have been allocated yet. If that happens there won't be 64KB of data to return, and the OS kernel will have to handle the situation. If no recovery mechanism has been defined, the process will be killed.
Depending on the design of the server software, it may recover from this automatically by simply spawning a new process. I think Apache would spawn a new process. Other software may not automatically respawn. In that case heartbleed could cause the server software to crash and stay down.
A complete crash of the operating system is not possible due to heartbleed. It would require a different bug to crash the operating system.