Failure to fetch client user object causes abort/crash

[InterLinked1]

Describe the bug

concord aborted and caused the entire program to crash.

Expected behavior

Program should not abort/crash. If the offending invariant can't be guaranteed, failure should be returned and the calling function can handle it.

Screenshots

22:15:25 FATAL discord-client.c:81:
        Assert Failed:  CCORD_OK == code
        Expected:       Couldn't fetch client's user object
Aborted (core dumped)

The assertion triggered is this one:

 if (new_client->token) { /* fetch client's user structure */
        CCORDcode code =
            discord_get_current_user(new_client, &(struct discord_ret_user){
                                                     .sync = &new_client->self,
                                                 });
        ASSERT_S(CCORD_OK == code, "Couldn't fetch client's user object");
    }

To Reproduce

This appeared to happen during initialization, though I don't have any more context than that. Offending line is discord_client = discord_init(token); Hasn't happened before in a year or two of running this. Unfortunately, this crash happened while I was out of office and caused an important production system to be offline for several days.

However, I believe this happened upon a reconnect attempt immediately due to the program exiting for another reason, so it's possible this can be triggered by immediately disconnecting and reconnecting. I have not tested that.

Version

0fa43731c8580ebe6ec344d4540c0cbfa155f97f

Stack trace

Thread 1 (Thread 0x7f8c3072c9c0 (LWP 1358231)):
#0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
        tid = <optimized out>
        ret = 0
        pd = <optimized out>
        old_mask = {__val = {140736242781024}}
        ret = <optimized out>
#1  0x00007f8c31236f1f in __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
#2  0x00007f8c311e7fb2 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
        ret = <optimized out>
#3  0x00007f8c311d2472 in __GI_abort () at ./stdlib/abort.c:79
        save_stage = 1
        act = {__sigaction_handler = {sa_handler = 0x20, sa_sigaction = 0x20}, sa_mask = {__val = {140239477154859, 140736242781248, 140239477679453, 0, 0, 0, 0, 0, 1, 0, 93915654582208, 0, 104, 140239477174506, 140239477419168, 140239477200176}}, sa_flags = 0, sa_restorer = 0x0}
#4  0x00007f8c0c365413 in _discord_init () at /usr/local/lib/libdiscord.so
#5  0x00007f8c0c3654f5 in discord_init () at /usr/local/lib/libdiscord.so
#6  0x00007f8c0c4390c0 in load_module () at mod_discord.c:1676
        __func__ = "load_module"
#7  0x0000556a7041bc4e in start_resource (mod=0x556a713ab730) at module.c:614

[lcsmuller]

Hello @InterLinked1, thank you for bringing this to our attention, you are absolutely right about this

failure should be returned and the calling function can handle it.

Will be fixed on the next release, I'll ping you when it's done. I'll also go through the entire codebase, as there are probably many other such cases

[lcsmuller]

Fixed in dev, rather than aborting it will now log an error and return a NULL