The 2024 Wheel Reinvention Jam just concluded. See the results.

pre-alpha 00.01.05

spx
This one is mostly fixes but also has some smaller features in it.
Without further ado, here is build 00.01.05.

CHANGELOG for this version
  • Added a new ",c" modifier to expressions to display memory as null-terminated string
  • Fixed highlighting in memory view for types bigger than 255 bytes
  • Fixed breakpoint highlighting for assembly lines
  • Memory view: Added tab key to quickly switch between editing bytes and characters
  • Fixed a bug in the memory allocator when compacting memory
  • Made the output window movable and resizable (both settings are not persistent at the moment)
  • Fixed a minor rendering issue for combo boxes
  • Fixed small misalignment in cursor hit detection on inline variables
  • Fixed a few cases where clicking on an inline variable member would insert the wrong expression into the watch window
  • Added a resize handle to memory views
  • Fixed setting the wrong task state when trying to kill a task that has already stopped
  • Only process memory regions that start at offset 0 into the file
  • Fixed interpretation of configs and ui.config without a trailing line break

In case you are new here
..and want to catch up on the WIP introduction of this project you can do this over here or watch some of the videos on the project page; most of these information you can also read on the patreon page.
This project has very ambitious goals because when we are honest with ourselves, debugging on Linux is in a pretty bad state; I personally want this project to be as good as I can possibly make it and if you are into native programming on Linux, you may have an interest in this as well.

Comments

Impressed with the speed of the releases/fixes! At this rate it will pretty solid in no time. You must have read my mind with the ",c" modifier, nice addition.

For version 1.05 and 1.04 the application has been hanging during startup. The main window opens but nothing else shows when this happens. This does not happen every time so I can't figure out exactly what is causing it. I have to kill both codeclap processes to close and try again. Have you seen this before or know what could cause this?


joe513
Impressed with the speed of the releases/fixes! At this rate it will pretty solid in no time. You must have read my mind with the ",c" modifier, nice addition.

For version 1.05 and 1.04 the application has been hanging during startup. The main window opens but nothing else shows when this happens. This does not happen every time so I can't figure out exactly what is causing it. I have to kill both codeclap processes to close and try again. Have you seen this before or know what could cause this?

indeed I have encountered this after finishing up 00.01.05 (didn't know it was also in .04). The unfortunate reason that I didn't see this before is that the environment I use for the "final" build is not the one I work in and apparently the issue only manifests in the former one. I've sneaked in a new archive into the build post that I compiled personally, if you are eager you could try that one. Of course this doesn't solve the issue; but I should get a fix in for this today.
pushed a 00.01.05-2 archive. This one should solve the issue you've encountered.
If it still hangs for you it could be helpful to know which distribution you are using, maybe there is some problem with the pthread mutex I am using to synchronize the reload of the configuration files.
I just tried 1.05-2 and the issue is still there. Distribution - Ubuntu 16.04.2 LTS
Let me know if you need any more information.
joe513
I just tried 1.05-2 and the issue is still there. Distribution - Ubuntu 16.04.2 LTS
Let me know if you need any more information.

this is an interesting one. I have yet to succeed in actually creating a bootable ubuntu usb stick but I have fallen back to test this in a VM and I am at least able to reproduce "a" freeze (with a bit of trying). I can't yet say if this is the one you are seeing. It seems to hang in a pthread_mutex_lock call but none I am doing myself (i've also removed the only mutex I use to test for any side effects). But there is quite some pollution from llvmpipe and I couldn't make sense of this just yet.
Also the one I am seeing is at least present in 00.01.02 as well.

// Update
Was able to reproduce this without VM+llvmpipe, will look into it.
Now that you mention it, I did see it on 00.01.02 also, just slightly different.

00.01.01 - .02



and 00.01.04 - .05

joe513
Now that you mention it, I did see it on 00.01.02 also, just slightly different.

This should be because at one point I've changed which parts of the frontend are rendered in which state.
I believe I've figured this out "sufficiently"; after crashing unity a few times.
There is now a 00.01.05-3 and I really hope this fixes the issue :). On one system I can still observe the effect that the X11 window is dangling (not very often) after the process has already exited (even added a call to XUnmapWindow and XDestroyWindow), but this can very well be a bug in Unity; the process isn't there anymore and the window disappears as soon something else X-related happens.
spx
joe513
Now that you mention it, I did see it on 00.01.02 also, just slightly different.

This should be because at one point I've changed which parts of the frontend are rendered in which state.
I believe I've figured this out "sufficiently"; after crashing unity a few times.
There is now a 00.01.05-3 and I really hope this fixes the issue :). On one system I can still observe the effect that the X11 window is dangling (not very often) after the process has already exited (even added a call to XUnmapWindow and XDestroyWindow), but this can very well be a bug in Unity; the process isn't there anymore and the window disappears as soon something else X-related happens.


Looks like you got it, I have opened and closed several times with no issues at all.
joe513
spx
joe513
Now that you mention it, I did see it on 00.01.02 also, just slightly different.

This should be because at one point I've changed which parts of the frontend are rendered in which state.
I believe I've figured this out "sufficiently"; after crashing unity a few times.
There is now a 00.01.05-3 and I really hope this fixes the issue :). On one system I can still observe the effect that the X11 window is dangling (not very often) after the process has already exited (even added a call to XUnmapWindow and XDestroyWindow), but this can very well be a bug in Unity; the process isn't there anymore and the window disappears as soon something else X-related happens.


Looks like you got it, I have opened and closed several times with no issues at all.

Unfortunately one of the threading changes has caused an unintended side effect with "waitpid" which now hits an assert when stopping a debugging session (which is good, because it wouldn't work). I am aware of this and will look into the best way of solving this.
..-4 has arrived. This is not a perfect fix but the issue is annoying enough and the handling for this situation should have no side effects and be reasonable.