chaining multiple key derivation functions together
Yes, there's an issue: you're adding needless complexity, which gives you absolutely no benefit.

The whole point of a PBKDF is to be slow; passwords are low-entropy, and the only way to mitigate brute-force is to make it take time to compute hashes. It can't take too long to log in, so you have to balance "fast for a user" and "slow for an attacker." Attackers use hashes differently than users; an attacker will be trying many, many, many combinations, possibly on specialized hardware, while a user only tries one password at a time.

The trouble with combining hashes is that you only have a certain amount of time and resources you can give your hashing process. If you take 200ms for PBKDF2, 200ms for bcrypt, and 200ms and 16 MB for scrypt, your system takes 600ms to compute a hash. Suppose that PBKDF2 hardware implementations are \$1.00 per 100 threads of PBKDF2; bcrypt ones are \$50.00 per 100 threads of bcrypt; scrypt ones are \$100 per 100 threads of scrypt (these numbers are wholly made up). Then an attacker can attack 300 hashes at once for a cost of \$151; this will check a new hash every 2ms on average. If you just used scrypt with 600ms and 16 MB required, then an attacker would need 300 scrypt threads to get that throughput; this is \$300.

Basically, the issue with combining them is that you're shifting hash time from a stronger algorithm (where it's expensive for the attacker to do things faster than you) into a weaker algorithm (where it's cheap for the attacker to do things faster you).