No, because you have not given so much information for anyone to help you.

You do array assigns in your code, but do not show how large the arrays are, so we can't see if you overwrite something else.

But you say you have run your code in the debugger. Don't the debugger show you what values you have in memory? Are they as expected? If not, where/when do they get changed?

By the way - is that interrupt really suited for emitting data to a 80x16 multiplexed displyay? I would have expected the code to shift out bits for a scanline, but you don't seem to pick up individual bits - or do you have a 80x16 byte large source array instead of a 80x2 (alternatively 10x16) byte source array.

You have a loop using two index [row] and [col], but remebmer that your processor do not like to do a dual-index lookup in your most critical loop - it has to do a multiply to figure out which byte to read.

I would have expected an unrolled loop to emit eight bits at maximum speed:

p = bitmap_data_for_current_scanline;
for (i = 0; i < bytes_in_shift_register; i++) {
    eight_bits = *p++;
    port_pin = eight_bits_0;
    clock_pin = high;
    clock_pin = low;
    port_pin = eight_bits_1;
    clock_pin = high;
    clock_low = low;
    ...
}

You should take advantage of your processors special abilities, instead of writing your code to suffer from its shortcomings.

Your processor is good at bit manipulation, so use that.
It is not good at indexed memory accesses, so minimize that.
And do trade code size for speed, and run unrolled inner loops to allow hard-coded addressing of your data.

Back to your problem. If you comment away different code lines, you should be able to figure out if any of your lines does overwrites memory. Then you know where to look for your problem with the interrupt handler returning to the wrong location. In the end, finding where live hardware fails can be really hard. Being able to get the same problem by single-stepping in a simulator means that you should be able to find the problem within the hour.