SIGSEGV in al_close_native_text_log when multiple log

Hello all,

I'm using Allegro native text logs to debug my project and use several of them depending of my needs (one for battle computing, one for artificial intelligence, ...).
When I use only one, everything is fine. However, when I try to use more, I get a SIGSEGV in al_close_native_text_log when I try to close the second one.

Here is some code, the problem occurs in the destructor of the SLogger:
Le Header:

1namespace ELog 2{ 3 enum Type 4 { 5 Battle, 6 AI, 7 Dummy, 8 9 Length 10 }; 11} 12 13class SLogger 14{ 15 private: 16 ALLEGRO_TEXTLOG* Logs[ELog::Length]; 17 18 private: 19 ~SLogger(); 20 21 public: 22 void LoadLogWindows(); 23 24 void Log(ELog::Type which, std::string text); 25};

Le Cpp:

1SLogger::~SLogger() 2{ 3 for(int i=0; i<ELog::Length; i++) 4 { 5 if(Logs[i] != NULL) 6 { 7 al_close_native_text_log(Logs[i]); 8 Logs[i] = NULL; 9 } 10 } 11} 12 13void SLogger::LoadLogWindows() 14{ 15 for(int i=0; i<ELog::Length; i++) 16 { 17 Logs[i] = NULL; 18 } 19 20 21 Logs[ELog::Battle] = al_open_native_text_log("Battle Log", ALLEGRO_TEXTLOG_NO_CLOSE | ALLEGRO_TEXTLOG_MONOSPACE); 22 23 Logs[ELog::AI] = al_open_native_text_log("AI Log", ALLEGRO_TEXTLOG_NO_CLOSE | ALLEGRO_TEXTLOG_MONOSPACE); 24 25Logs[ELog::Dummy] = al_open_native_text_log("AI Log", ALLEGRO_TEXTLOG_NO_CLOSE | ALLEGRO_TEXTLOG_MONOSPACE); 26}

Is it a known problem or have I done something wrong?

Peter Wang

I can't test right now but just from reading the code, yes, this is likely a problem on Windows and OS X.


That's odd. I have just checked, and it works fine, no matter how many logs.

Are you sure there's nothing messes with pointers? Because the only way I'm getting segfaults at log closure is artificially messing with them, like this:


Segfaults also arise when I close exactly the same log more than once. Make sure you don't do that either.


Informations I should have given on the first post:
I'm using allegro 5.0.6 on Windows 7.

The only function to have access to those pointer is the writing function which goes like this:

void SLogger::Log(ELog::Type which, std::string text)
    Assert((Logs[which] != NULL), "Log doesn't exist. This may be a define error.");

    al_append_native_text_log(Logs[which], "%s\n", text.c_str());

And the problem arise even if I don't use it.

When I watch them in the debugger, the different pointers are different so it seems I'm not closing the same window twice. Could it be that Windows link them in some sort of way because they are spawned by the same process?


Oh, that. I'm using 5.0.7 on W764 with gcc 4.6 and it works with no problem. Maybe you should upgrade, API haven't changed anyway.

On unrelated topic, why would you check whether or not the log window you log into actually exists? Isn't it obvious that if you manually specify where to log then you're confident about this being possible?

Peter Wang

I was wrong, this is specific to the Windows port. Here is the bug, I think:

diff --git a/addons/native_dialog/win_dialog.c b/addons/native_dialog/win_dialog.c
index 3cc6710..6f35b53 100644
--- a/addons/native_dialog/win_dialog.c
+++ b/addons/native_dialog/win_dialog.c
@@ -600,8 +600,8 @@ bool _al_open_native_text_log(ALLEGRO_NATIVE_DIALOG *textlog)
    /* Release RichEdit module. */
    if (wlog_rich_edit_module) {
-      _al_close_library(wlog_rich_edit_module);
-      wlog_rich_edit_module = NULL;
+//       _al_close_library(wlog_rich_edit_module);
+//       wlog_rich_edit_module = NULL;
    /* Unregister window class. */


I've updated to 5.0.7 without it solving the problem.

And for the second question, let's say I'm a control freak. The Assert aren't included in the release version so I put a lot of them.

@Peter Wang:
I can't really go into Allegro to apply the change you are suggesting since I use the binary version.
Do you have any workaround? (I don't know what RichEdit is, maybe there is a way to deactivate it.)

Peter Wang

Wait for the next release or don't use multiple text logs.

edit: fixed in git


Okay. I'll use logging on file instead of extra windows.

Thanks for the answers.

Thread #611252. Printed from