1.please give me an example of additional input for software cryptographic library
Here is one example of a use for it; suppose you are generating DSA (or ECDSA) signatures, and you don't know if you have good entropy. Now, the first thing the DSA signature algorithm does is select a random value $k$; if our random generator gives us the same value of $k$ twice, and we sign two different messages, someone looking at the signatures (and the messages being signed) can deduce our private DSA key (which is bad).
The concern is if we start our program, sign a message (which gets a value $k$ from our rng), then restart our program (with the same entropy), sign a different message (getting the same value $k$ from the same rng), and that'd leak the DSA private key.
Now, having bad entropy breaks a bunch of security things, but few as bad as this; it'd be nice if we had extra protection against this.
One approach is to do this: when we sign a message, we hash it, and provide it as additional input when we access the rng for the value $k$. If we have good entropy, this is harmless; if we have bad entropy, and are signing two different messages, the different additional inputs will give us unrelated values of $k$, and so we're safe; if we have bad entropy, and are signing two identical messages, we'll get the same value of $k$; however that does not leak the DSA private key (as the signatures will be precisely identical).
Now, this isn't the only way to protect ourselves from bad entropy breaking our DSA signatures (there is RFC6979 by our own Thomas Pornin); however it is an example of a reason you could plausibly use additional input.
And, for your other question:
2.Is additional input is crucial to DRBG security?
Of course not, if it was crucial, it wouldn't be optional. Instead, it is provided as a capability that the application can use, in case they suspect that the RNG state might have inferior entropy (as above), or it might have been compromised.