Fixing memory leaks using exceptions #2620

pgScorpio · 2022-04-26T23:53:53Z

Short description of changes

Fix some memory leaks.
Alternative for PR #2618 using exceptions to cleanly exit the application.
(#2618 won't solve the problem when still using exit() or on other unhandled exceptions.)

CHANGELOG:
Fixed some memory leaks in main.

Context: Fixes an issue?

Fixes #2614

Does this change need documentation? What needs to be documented and how?

No documentation changes

Status of this Pull Request

Bugfix

What is missing until this pull request can be merged?
Review

Checklist

I've verified that this Pull Request follows the general code principles
I tested my code and it does what I want
My code follows the style guide
[-] I waited some time after this Pull Request was opened and all GitHub checks completed without errors.
I've filled all the content above

Moved pointers to with new assigned objects outside main and added a cleanup function that is called before every exit to delete those objects again.

Forgot to use the right pApp pointer in headless mode.

Added CErrorExit and CInfoExit exception classes to exit the application in a clean way.

pgScorpio · 2022-04-27T00:10:11Z

src/main.cpp

+    try
    {



Sorry, but because of moving this try, the indenting changed on a large part of the code and now, in combination with some moved code, the diff becomes very confusing...

You probably better open both files side by side....

There's a "Hide whitespace" option for Github, and for git there is git diff -w

-w
--ignore-all-space

Ignore whitespace when comparing lines. This ignores differences even if one line has whitespace where the other line has none.

Making shure the type of pApp stays the same as it used to be. Bugfix exit_code CGenErr on gui.

activity and pApp don't exist anymore outside the try block.

ExitCode now also in GenErr Moved ExitCode param for ErrorExit to last param with default Catching standard exeptions Fixed QCoreApplication/QApplication usage.

ann0see · 2022-04-28T20:42:39Z

@dtinth could you please Review this PR?

In the code we use bUseGUI to select between QApplication and QCoreApplication. But since QApplication is not defined in HEADLESS builds we have to use a lot of extra ifdef's. But by defining QApplication the same as QCoreApplication in HEADLESS builds we no longer need those ifdefs.

ann0see

The diff isn't that clear on GitHub... But see some comments.

src/global.h

src/main.cpp

ann0see · 2022-04-30T19:20:10Z

src/main.cpp

+#include "settings.h"
+#include "util.h"
+#include <memory>


Did you just move code around here? Why?

To keep things more clear....
All those ifdef's are confusing enough, so whenever possible let's keep common things together...

Ok. I hope it doesn't have any side-effects.

Better to avoid making unnecessary changes entirely.

Better to avoid making unnecessary changes entirely.

In my opinion that is one of the main problems in the Jamulus development.
Just fixing bugs locally, without solving the real cause of the bug... often poor framework...
Improvements of the framework aren't "unnecessary changes"!
Real development is continuously improving the framework to prevent future similar bugs.
So you should strive for solutions that work in any case, not just for the bug you are fixing.

ann0see · 2022-04-30T19:22:58Z

src/main.cpp


 // Implementation **************************************************************

 int main ( int argc, char** argv )
 {
+    int exit_code = 0;


Give a comment here why we need the variable. (I still don't like having an exit code variable here...)

Hmmm Why not ? Its the return value of main, and it's quite common practice to declare the returned value as first in a function.

Its the return value of main, and it's quite common practice to declare the returned value as first in a function.

But I don't see any other places in Jamulus where functions have this?

But I don't see any other places in Jamulus where functions have this?

Perhaps you have to look better than ;=))

Just do a search on return ret , return res or return result and you will already find a bunch of them...
Or search for return _id; since also all qt_metacall moc_ functions use this coding pattern!
Or take a look look at:

CChannel::SetSockBufNumFrames
CChannel::PutAudioData
CChannel::GetData
CProtocol::GetValFromStream
CNetBuf::Get
CNetBufWithStats::Get
CBuffer::GetAvailData()
CClient::GetAndResetbJitterBufferOKFlag()
CServer::CreateChannelList()
CServer::FindChannel
CServer::PutAudioData
CServer::CreateLevelsForAllConChannels
CSettings::GetIniSetting
CSettings::GetNumericIniSet
CSettings::GetFlagIniSet
...
All the same pattern, just different variable names....

This really is a standard coding practice....

No. This is not necessary - just use return directly.

No. This is not necessary - just use return directly.

No! actually we should use Application.exit() anywhere outside main, and so we need the return value of Application.exec()

ann0see · 2022-04-30T19:25:11Z

src/main.cpp

+        // TODO create settings in default state, if loading from file do that next, then come back here to
+        //      override from command line options, then create client or server, letting them do the validation
+        //
+        // See https://github.com/pgScorpio/jamulus/tree/first-big-thing-for-settings for a possible solution on that


Please remove this comment since it's just a short therm one. I hope in future we'd have a PR.

The TODO is not my comment....
And I added the link to my solution in another attempt to get the settings discussion going... (After several failed attempts.)
Nevertheless, there are still a lot PR to merge in main, so I will remove it eventually... ;-)

Still the link seems to be new. I'd rather NOT have future fixes in the code. Either fix them right away - that's out of scope of this PR - or document it on GitHub.

Still the link seems to be new.

Yes. As I said "I added the link"... "in another attempt to get the settings discussion going"

But I get your point... I hope you get my point too. ;=))

What ann0see said.

src/main.cpp

ann0see · 2022-04-30T19:26:42Z

src/main.cpp

@@ -903,15 +965,15 @@ int main ( int argc, char** argv )

                // show dialog


Why isn't the exit-code variable here?

Since here main always returns 0 and we only did set an exit code with exit(1), but in the new situation we wanna do the clean up, so we don't wanna use exit(), but we will return from main normally, so main must return the exit code.

Co-authored-by: ann0see <20726856+ann0see@users.noreply.github.com>

atsampson · 2022-04-30T21:48:43Z

Can I suggest a simpler solution that combines ideas from both of your approaches?

The only uses of exit outside of main are in the option-parsing functions, which are only used before any of the dynamic allocations happen anyway. So turning the exit calls in main into straightforward returns will guarantee that stack-allocated objects in main are destroyed properly.

You can then convert the pointer variables into smart pointers, adding new smart pointers for the RPC classes that didn't have them already as you've done above.

I've put a quick attempt at this on the atsampson:scopedexit branch. I haven't tested this with all the combinations of configuration options but it should give you an idea of what I mean...

pgScorpio · 2022-04-30T22:18:30Z

@atsampson

Can I suggest a simpler solution that combines ideas from both of your approaches?

Thanks for the suggestion !
But...
For the current code that would be almost right. Though exit(1) is also used in the commandline parsing functions, and return can't be used there. Also there a several PR's pending that would also need an exception solution, that's why I changed to using exceptions.

EDIT: BTW Where are the with new allocated instances deleted ???, that was the original memory leak problem....

atsampson · 2022-04-30T22:54:45Z

For the current code that would be almost right. Though exit(1) is also used in the commandline parsing functions, and return can't be used there.

That's fine, because the option-parsing functions are only used before any of the dynamic allocation happens. There's a comment noting this in my changes.

BTW Where are the with new allocated instances deleted ???

QScopedPointer is a smart pointer class; it's roughly Qt's equivalent of std::unique_ptr. It deletes the pointer it's holding automatically when it goes out of scope, so the object will be destroyed correctly when the function exits (either via return or through an exception). If you haven't encountered smart pointers before, I'd definitely recommend reading up on them - there's rarely a good reason to use delete in modern C++.

pgScorpio · 2022-04-30T23:36:23Z

QScopedPointer is a smart pointer class; it's roughly Qt's equivalent of std::unique_ptr. It deletes the pointer it's holding automatically when it goes out of scope, so the object will be destroyed correctly when the function exits (either via return or through an exception)

Yes I know smart pointers, I even considered using them. But they have some disadvantages too.
1: They only work when there is a well defined scope. And the rpc classes don't have a well defined scope in the current implementation.
2: No garantee in wich order they are deleted if they are in the same scope (often same order as creation). And since the pointers are cross referenced we need to delete them in a specific order (reverse order of creation).

So I still think the exception solution is the simplest and most reliable, since it works under all circumstances...

atsampson · 2022-05-01T02:55:14Z

No garantee in wich order they are deleted if they are in the same scope (often same order as creation).

No, that's not correct. In C++, variables with automatic storage duration (i.e. locals) are guaranteed to be destroyed in reverse order of construction - see the language standard or the ISO C++ FAQ. If that wasn't the case, then lots of RAII idioms wouldn't work.

And the rpc classes don't have a well defined scope in the current implementation.

... which means they do have a well-defined lifetime if you convert them to smart pointers - they will be deleted in reverse order of the declarations when main exits. You want to ensure that the RPC objects are deleted before the objects they're controlling, which matches the declaration order in the current code.

There's absolutely nothing wrong with using exceptions to cause a clean exit from elsewhere in the code - one of the reasons smart pointers were added to the standard library was to simplify memory management when exceptions are being used, and if you're adding more use of exceptions then you may well find that there are other places in the code where you can replace manual memory management with smart pointers to avoid complex cleanup code.

pgScorpio · 2022-05-01T12:28:22Z

@atsampson
Thanks for the information.
If this is true (though I encountered several occasions where it didn't work this way) we could use smart pointers here to do the cleanup (and so it also should be done on a lot of other places in the code),
but see the note:

Note [2] However, the program can be terminated (by calling std::exit() or std::abort() for example) without destroying objects with automatic storage duration — end note]

So we still should use exceptions instead of exit. I don't like to rely on the fact that no pointers or other objects are assigned before using exit. This might (and will) change in the future, so it would be safer to state "NEVER use exit but use the CErrorExit exception.

ann0see · 2022-05-02T19:07:03Z

src/main.cpp


 // Implementation **************************************************************

 int main ( int argc, char** argv )
 {
+    int exit_code = 0;


Its the return value of main, and it's quite common practice to declare the returned value as first in a function.

But I don't see any other places in Jamulus where functions have this?

ann0see · 2022-05-02T19:08:35Z

src/main.cpp

+        // TODO create settings in default state, if loading from file do that next, then come back here to
+        //      override from command line options, then create client or server, letting them do the validation
+        //
+        // See https://github.com/pgScorpio/jamulus/tree/first-big-thing-for-settings for a possible solution on that


Still the link seems to be new. I'd rather NOT have future fixes in the code. Either fix them right away - that's out of scope of this PR - or document it on GitHub.

ann0see · 2022-05-02T19:09:13Z

src/main.cpp

+        if ( bUseGUI )
+        {
+            pApplication = new QApplication ( argc, argv );
+        }
+        else
+        {
+            pCoreApplication = new QCoreApplication ( argc, argv );
+        }


Leaving this section up to @hoffie

src/main.cpp

ann0see · 2022-05-15T06:20:27Z

@atsampson @pgScorpio what's the agreement on the other discussed solution I think @pgScorpio wanted to use exceptions?

pgScorpio · 2022-05-15T14:11:24Z

@atsampson @pgScorpio what's the agreement on the other discussed solution I think @pgScorpio wanted to use exceptions?

Correct. Since the exception solution will also work where normally exit() would be used elsewhere, while the other method only works when exiting from main()

atsampson · 2022-05-15T15:57:43Z

@ann0see The only thing I'm really uncomfortable about here is the manual cleanup code using delete - it really should be using smart pointers in modern C++. I'm fine with adding an exception specifically to handle the option parsing errors - there's no advantage in terms of the original fault, but it does simplify the code in the parsing functions. If the exception rework goes beyond that, then I think it would be better to review it later when it's needed.

pgScorpio · 2022-05-15T17:21:36Z

The only thing I'm really uncomfortable about here is the manual cleanup code using delete - it really should be using smart pointers in modern C++.

I agree that using smart pointers would be a better solution, but AFAIK, besides in CSignalHandler, it's nowhere else used in the code, but though not specifically the solution for the original problem, it could be implemented here as well, though I think that should better be a separate PR, replacing all pointers with smart pointers...

I'm fine with adding an exception specifically to handle the option parsing errors - there's no advantage in terms of the original fault, but it does simplify the code in the parsing functions.

If the exception rework goes beyond that, then I think it would be better to review it later when it's needed.

And as you say yourself, it's already used in the option parsing functions... And this will be even more neccesay if we implement the commandline options class(es).

ann0see · 2022-05-15T19:35:16Z

Ok. So @atsampson @pgScorpio could you please open an issue on that?
What's the state of this PR? Can @atsampson do a review so that we are a bit closer to a merge?

atsampson

Review added as requested.

atsampson · 2022-05-15T20:49:34Z

src/global.h

-/* Classes ********************************************************************/
+/* Exception Classes **********************************************************/
+
+class CInfoExit


Don't add this class. It's only used to replace exit(0); from main, which should just be return 0;. It's bad style in C++ to use exceptions for handling normal situations.

It's bad style in C++ to use exceptions for handling normal situations.

It's what you call a "normal" situation...
But I agree that, just for the --help and --version, it could be a return ( 0 ).

atsampson · 2022-05-15T20:53:24Z

src/global.h

+
+    QString GetErrorMessage() const { return strErrorMsg; }
+
+    int GetExitCode() const { return iExitCode; }


The exit code is always 1 on error in the code below, so iExitCode isn't needed. (You might want to add this in the future if there's really a good reason to have different exit codes, but I think that's very unlikely to be useful in Jamulus, and it's certainly not needed now.)

The exit code is always 1 on error in the code below, so iExitCode isn't needed. (You might want to add this in the future if there's really a good reason to have different exit codes, but I think that's very unlikely to be useful in Jamulus, and it's certainly not needed now.)

I agree the exit code is (strangely enough) always 1 in this code, but as said we should provide a framework with general solutions, not prohibiting any 'normal' behavior.
Prohibiting any 'normal' behavior now will possibly lead to unwanted 'solutions' in the future.

atsampson · 2022-05-15T20:55:33Z

src/global.h

+    QString strInfoMsg;
+};
+
+class CErrorExit


I'd call this something like CCmdLineErr, to indicate what it's actually being used to report.

I'd call this something like CCmdLineErr, to indicate what it's actually being used to report.

Again, this is a 'universal' solution, so not only usable for commandline errors, so why name it that way just because we now use it for commandline errors?

I assume we can leave it as is - if we use it in future (and I think there is work coming up by @pgScorpio which uses it)

atsampson · 2022-05-15T20:56:06Z

src/global.h

@@ -359,6 +394,9 @@ class CCustomEvent : public QEvent
 };

 /* Prototypes for global functions ********************************************/
+


Not used - remove.

Again, Provide a Framework that should (and will) be used in the near future...

atsampson · 2022-05-15T20:57:06Z

src/main.cpp

@@ -22,10 +22,23 @@
 *
 \******************************************************************************/

+#ifdef HEADLESS


Don't change this - keep the changes to the minimum necessary to fix the problem.

atsampson · 2022-05-15T21:06:50Z

src/main.cpp

+        // TODO create settings in default state, if loading from file do that next, then come back here to
+        //      override from command line options, then create client or server, letting them do the validation
+        //
+        // See https://github.com/pgScorpio/jamulus/tree/first-big-thing-for-settings for a possible solution on that


What ann0see said.

atsampson · 2022-05-15T21:09:10Z

src/main.cpp


-// clicking on the Mac application bundle, the actual application


Explain in the commit message why removing this is safe (presumably it wasn't reached originally because of the qCritical - but I'd check the Git history to see why it was added).

Yes, this was a strange exception....
Since 1. I tested it on macOS and didn't see any strange behavior, and 2. the same exit ( 1 ) is used in multiple places, so if it really was a problem it should have been implemented in multiple places...

But yeah, I should have mentioned it...

atsampson · 2022-05-15T21:11:33Z

src/main.cpp


-    // Application/GUI setup ---------------------------------------------------
-    // Application object
-#ifdef HEADLESS


This is where you should have QScopedPointer<QCoreApplication> pApp; - see my branch. You don't need it to be of different types in the headless/non-headless cases, because QApplication is a subclass of QCoreApplication and has a virtual destructor.

You can then remove all of the extra conditionals that you've added below because of splitting this into two variables.

You don't need it to be of different types in the headless/non-headless cases, because QApplication is a subclass of QCoreApplication and has a virtual destructor.

Yes it has a virtual destructor, but there are a lot of other functions that are NOT virtual. Even exec() is NOT virtual and calling exec() As QCoreApplication while it actually is a QApplication will skip some GUI initialization.
So yes the pointer HAS to be the correct type.

atsampson · 2022-05-15T21:13:56Z

src/main.cpp

 // TEST -> activate the following line to activate the test bench,
 //CTestbench Testbench ( "127.0.0.1", DEFAULT_PORT_NUMBER );
 // clang-format on
 #endif

-    CRpcServer* pRpcServer = nullptr;


Smart pointer here - plus smart pointers for CServerRpc and CClientRpc - see my branch.

atsampson · 2022-05-15T21:15:30Z

src/main.cpp

+        exit_code = -1;
+    }
+
+    if ( pServerRpc )


Not needed with a smart pointer. (But even if it was, you never need to write if (x) delete x; - delete NULL; is guaranteed to do nothing.)

Just a (good?) habit of me to always check for null pointers ;=)
But you are right, it's not necessary here....

ann0see · 2022-05-15T21:21:35Z

@atsampson Thanks for the review ;-).
I think it's quite close to the KISS principle and "hard core Jamulus like".

pgScorpio · 2022-05-16T14:54:29Z

@ann0see

I think it's quite close to the KISS principle and "hard core Jamulus like".

May I note that the KISS principle refers to the implementation of (unnecessary) functionality, NOT the way the code is implemented. "Simple and Stupid" code implementation will always lead to more and more problems and bugs....
That's the whole idea behind my 'improvement' PR's, improving the framework to make maintaining the code easier and less prone to bugs...

ann0see · 2022-05-16T19:26:21Z

Yes. Probably. However the history of Jamulus was quite radical with code changes. It doesn't need to be like that - at least it's probably not up to me, but "the community" to decide.
The goal should be simple, extendable, unbloated code which doesn't do more than it needs to do. I think the refactoring of the Autobuild was a good example on simplification.

ann0see · 2022-05-26T08:19:00Z

Not sure if that's a good idea, but I think for your PRs (especially the sound related redesign, I think it would be worth having npostavs and corrados as reviewers). I know corrados is officially no longer part of the Jamulus Team, however he has the most insight probably.

ann0see · 2022-06-05T11:55:05Z

@jamulussoftware/maindevelopers how do we proceed here? I think the review by @atsampson has valid input, but I'm not fully sure how to continue (especially since - as discussed internally - some team members don't quite see the improvements).

I'd like someone like corrados to review sound redesign related changes (maybe not this one) since he's probably most familiar with the sound code.

pljones · 2022-09-04T10:14:29Z

Moving out to 3.10.0 as no clear fix identified.

pljones · 2023-04-19T15:03:12Z

Moving back to Triage until a way forward is proposed (and removing milestone).

pljones · 2023-09-18T18:29:41Z

Setting to draft as branch needs conflict resolution.

pljones · 2024-05-06T09:09:30Z

Closing as no activity in two years.

pgScorpio added 4 commits April 26, 2022 21:42

Fixing memory leaks.

2ecdb7f

Moved pointers to with new assigned objects outside main and added a cleanup function that is called before every exit to delete those objects again.

Bugfix pClientRpc does not exist in server-only mode

affd49d

Bugfix headless mode

e090359

Forgot to use the right pApp pointer in headless mode.

Solving some memory leaks again, but now using exceptions to exit.

e6b31f3

Added CErrorExit and CInfoExit exception classes to exit the application in a clean way.

pgScorpio mentioned this pull request Apr 26, 2022

Fixing memory leaks. #2618

Closed

4 tasks

pgScorpio commented Apr 27, 2022

View reviewed changes

pgScorpio added 3 commits April 27, 2022 16:47

Bugfixes pApp pointer type and exit code

ae873c1

Making shure the type of pApp stays the same as it used to be. Bugfix exit_code CGenErr on gui.

Buffix wrong pointertype pApplicationInstance

5d0cf53

Bugfix macOS

14128cb

activity and pApp don't exist anymore outside the try block.

ann0see added this to the Release 3.9.0 milestone Apr 27, 2022

ann0see added the refactoring Non-behavioural changes, Code cleanup label Apr 27, 2022

ann0see requested a review from hoffie April 27, 2022 19:56

Optimizing exception handling

271d2b1

ExitCode now also in GenErr Moved ExitCode param for ErrorExit to last param with default Catching standard exeptions Fixed QCoreApplication/QApplication usage.

pgScorpio mentioned this pull request Apr 28, 2022

Adding global commandline parameters #2599

Draft

5 tasks

ann0see reviewed Apr 30, 2022

View reviewed changes

pgScorpio and others added 2 commits April 30, 2022 22:17

Update src/main.cpp

d04c899

Co-authored-by: ann0see <20726856+ann0see@users.noreply.github.com>

Update src/main.cpp

de39150

Co-authored-by: ann0see <20726856+ann0see@users.noreply.github.com>

ann0see reviewed May 2, 2022

View reviewed changes

atsampson suggested changes May 15, 2022

View reviewed changes

pljones modified the milestones: Release 3.9.0, Release 3.9.1 Jun 18, 2022

gilgongo added this to Triage in Tracking (old) via automation Jul 2, 2022

gilgongo moved this from Triage to Waiting on Team in Tracking (old) Jul 2, 2022

pljones moved this from Waiting on Team to Backlog in Tracking (old) Aug 29, 2022

pljones moved this from Backlog to Triage in Tracking (old) Sep 4, 2022

pljones modified the milestones: Release 3.9.1, Release 3.10.0 Sep 4, 2022

pljones moved this from Triage to Backlog in Tracking (old) Oct 5, 2022

ann0see changed the base branch from master to main December 26, 2022 19:09

pljones removed this from the Release 3.10.0 milestone Apr 19, 2023

pljones moved this from Backlog to Triage in Tracking (old) Apr 19, 2023

pljones removed this from Triage in Tracking (old) Jul 28, 2023

pljones added bug Something isn't working and removed refactoring Non-behavioural changes, Code cleanup labels Aug 12, 2023

pljones marked this pull request as draft September 18, 2023 18:29

pljones added this to the Release 3.12.0 milestone May 6, 2024

pljones closed this May 6, 2024

		@@ -903,15 +965,15 @@ int main ( int argc, char** argv )

		// show dialog


		QString GetErrorMessage() const { return strErrorMsg; }

		int GetExitCode() const { return iExitCode; }

		@@ -359,6 +394,9 @@ class CCustomEvent : public QEvent
		};

		/* Prototypes for global functions ********************************************/


		// clicking on the Mac application bundle, the actual application

Fixing memory leaks using exceptions #2620

Fixing memory leaks using exceptions #2620

Conversation

pgScorpio commented Apr 26, 2022 • edited Loading

Checklist

pgScorpio Apr 27, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ann0see commented Apr 28, 2022

ann0see left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

atsampson commented Apr 30, 2022

pgScorpio commented Apr 30, 2022 • edited Loading

atsampson commented Apr 30, 2022

pgScorpio commented Apr 30, 2022 • edited Loading

atsampson commented May 1, 2022

pgScorpio commented May 1, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ann0see commented May 15, 2022

pgScorpio commented May 15, 2022

atsampson commented May 15, 2022

pgScorpio commented May 15, 2022

ann0see commented May 15, 2022

atsampson left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ann0see commented May 15, 2022 • edited Loading

pgScorpio commented May 16, 2022

ann0see commented May 16, 2022

ann0see commented May 26, 2022

ann0see commented Jun 5, 2022

pljones commented Sep 4, 2022

pljones commented Apr 19, 2023

pljones commented Sep 18, 2023

pljones commented May 6, 2024

pgScorpio commented Apr 26, 2022 •

edited

Loading

pgScorpio Apr 27, 2022 •

edited

Loading

pgScorpio commented Apr 30, 2022 •

edited

Loading

pgScorpio commented Apr 30, 2022 •

edited

Loading

pgScorpio commented May 1, 2022 •

edited

Loading

ann0see commented May 15, 2022 •

edited

Loading