Jump to content
The Dark Mod Forums

DarkRadiant 2.8.0 pre-release testing


Recommended Posts

There is nothing problematic in that stack trace, which makes me think that it is showing a thread which hasn't actually crashed (but there may be another thread which has crashed).

If you use the command info threads, gdb should list all the threads which are currently running. Does any thread in that list have associated text indicating it has crashed ("stopped", "aborted" etc)?

Link to comment
Share on other sites

On 4/9/2020 at 1:32 AM, greebo said:

Wow, it doesn't get very far, it's stuck right in glib?

I notice you're running Wayland, which wxWidgets doesn't support. Are you using Gnome?

I have wayland installed, but have not yet had success getting it to work with nvidia. Still running Plasma in X11. Maybe I'll try uninstalling wayland anyway.

Edited by PranQster
  • Like 1

System: Mageia Linux Cauldron, aka Mageia 8

Link to comment
Share on other sites

On 4/9/2020 at 4:34 AM, OrbWeaver said:

There is nothing problematic in that stack trace, which makes me think that it is showing a thread which hasn't actually crashed (but there may be another thread which has crashed).

If you use the command info threads, gdb should list all the threads which are currently running. Does any thread in that list have associated text indicating it has crashed ("stopped", "aborted" etc)?

Thank you. I'm a newb to debugging. I'll try this.

  • Like 1

System: Mageia Linux Cauldron, aka Mageia 8

Link to comment
Share on other sites

A little progress. I installed the debug info package for glibc and then ran it and did info threads with the following results. I'm going to try to install more of the listed missing debug info packages and see if I get more results. *(that didn't produce anything different)

Starting program: /usr/bin/darkradiant 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7ffff0479700 (LWP 11341)]
[New Thread 0x7fffefc78700 (LWP 11342)]

Thread 2 "gmain" received signal SIG33, Real-time event 33.
[Switching to Thread 0x7ffff0479700 (LWP 11341)]
0x00007ffff61dc3af in __GI___poll (fds=0xe844d0, nfds=1, timeout=-1)
    at ../sysdeps/unix/sysv/linux/poll.c:29
29        return SYSCALL_CANCEL (poll, fds, nfds, timeout);
(gdb) info threads
  Id   Target Id                                       Frame 
  1    Thread 0x7ffff20569c0 (LWP 11337) "darkradiant" setxid_signal_thread (t=0x7ffff0479700, 
    cmdp=0x7fffffffd700) at allocatestack.c:1035
* 2    Thread 0x7ffff0479700 (LWP 11341) "gmain"       0x00007ffff61dc3af in __GI___poll (
    fds=0xe844d0, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
  3    Thread 0x7fffefc78700 (LWP 11342) "gdbus"       0x00007ffff61dc3af in __GI___poll (
    fds=0xe965d0, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
(gdb) 

 

Edited by PranQster
  • Like 1

System: Mageia Linux Cauldron, aka Mageia 8

Link to comment
Share on other sites

Yes, I have mostly used DR in linux in the past, but every now and then have needed to switch to using wine. It's been a while since I had been using DR, so I don't remember which version I had used previously but it was what was current about a year ago.

  • Like 1

System: Mageia Linux Cauldron, aka Mageia 8

Link to comment
Share on other sites

In trying to fix this, I have been looking for unnecessary devel packages which I may have previously installed. I found that I had both 64 and 32 bit versions of freetype-devel. Since the only thing I ever enabled 32bit repositories for is wine, and I'm no longer running any 32-bit programs in wine, I decided that it should be chucked. After removing the 32 bit version I got errors compiling DR. I re-installed the (already installed) lib64freetype2-devel and make continued as it should. This is now looking to be a likely culprit. Awaiting make to finish right now to see if the new built darkradiant works...

And that was not the issue... still segfaults.

Edited by PranQster
  • Like 1

System: Mageia Linux Cauldron, aka Mageia 8

Link to comment
Share on other sites

It is highly unlikely that the presence of any particular -devel package on your system is going to cause DR to crash, unless that devel package is so horribly broken that it actually breaks software that is compiled while it is installed (which is very unlikely in the first place, and such a package would almost certainly be removed by the distribution).

  • Like 1
Link to comment
Share on other sites

13 hours ago, OrbWeaver said:

It is highly unlikely that the presence of any particular -devel package on your system is going to cause DR to crash, unless that devel package is so horribly broken that it actually breaks software that is compiled while it is installed (which is very unlikely in the first place, and such a package would almost certainly be removed by the distribution).

True, but I needed to make sure to get rid of the 32bit devel packages. I was a bit surprised that make couldn't find freetype after removing the 32bit freetype-devel, though the 64bit version was already installed. Not knowing what is at fault is certainly making this more challenging.

System: Mageia Linux Cauldron, aka Mageia 8

Link to comment
Share on other sites

Fixed! I'm running DR Linux native again.

After another round of system updates and a fresh build of DR I decided to check out the installation path before I ran 'make install'. In /usr/lib/darkradiant were several old links to libraries from past installations (in addition to the current libraries). So I manually deleted /usr/bin/darkradiant and the contents of /usr/lib/darkradiant and /usr/share/darkradiant. Then I ran 'make -install' and *presto* DR now works :) Though running it in wine works, changes to the camera do not update until the mouse is used, making every single change require an extra mouse movement, scroll, or click. 

Thank you all for putting up with me.

Edited by PranQster
  • Like 2

System: Mageia Linux Cauldron, aka Mageia 8

Link to comment
Share on other sites

4 hours ago, PranQster said:

After another round of system updates and a fresh build of DR I decided to check out the installation path before I ran 'make install'. In /usr/lib/darkradiant were several old links to libraries from past installations (in addition to the current libraries). So I manually deleted /usr/bin/darkradiant and the contents of /usr/lib/darkradiant and /usr/share/darkradiant. Then I ran 'make -install' and *presto* DR now works :) Though running it in wine works, changes to the camera do not update until the mouse is used, making every single change require an extra mouse movement, scroll, or click.

When I'm doing development I always build DR with a custom path, e.g.:

$ ./configure --prefix=/tmp/dr
$ make -j8 install

This will completely avoid any conflicts with existing installation, and also provides the benefit that root privileges are not required at any point (because the /tmp directory is world-writeable). Obviously this is no use as a permanent solution (unless you use a persistent custom path like /opt/darkradiant-1.8) but is useful for testing and development purposes.

In any case, I'm glad you finally got it working on your system.

Link to comment
Share on other sites

Glad you got it to run!

On 4/8/2020 at 1:54 AM, PranQster said:

(140385119140288) ModuleLoader: loading modules from /usr/lib/darkradiant (140385119140288) ModuleLoader: Loading module '/usr/lib/darkradiant/modules/md5model.so'

Oh, well, the above log lines should have triggered my attention, in hindsight. There is no md5model module to be loaded by DR anymore, so this should have made the problem of old incompatible binaries lying around obvious for me... 😕

Link to comment
Share on other sites

Something is not right with the UI though. Will try to re-build it with lib64wxgtku3.1-devel instead of lib64wxgtku3.0-devel.

Yep! That did the trick. The UI is responding as it should. I was having trouble with the UI refreshing without having to manually resize the orthoview, no vectors when pressing 'v', and other issues.

Edited by PranQster

System: Mageia Linux Cauldron, aka Mageia 8

Link to comment
Share on other sites

Is there a technical reason that the Brush->Sphere is limited to only 7?

Would love to have one with 32 sides at least.

 

EDIT: I see in the code it's set to max 7, (brush.cpp line 46: const std::size_t Brush::SPHERE_MAX_SIDES = 128;)

I set it to 128 and I can create a sphere with 32 sides, looks great.
I tried higher but the brush just disappears.

 

EDIT 2: Hmm, clipper doesn't work on it though. I can see the preview of the 2 points cutting line, but when I hit Enter, nothing happens. No errors or warnings in the console either.

EDIT 3: And Dmap crashes lol

I always assumed I'd taste like boot leather.

 

Link to comment
Share on other sites

Running debug version of TDM, looks like a memory allocation error?

    for (;;)
    {
        void* const block = HeapAlloc(__acrt_heap, 0, actual_size);
        if (block)
            return block;

 

>    TheDarkModx64.exe!_malloc_base(unsigned __int64 size) Line 34    C++

 

Guess this needs to go in another thread.

  • Like 1

I always assumed I'd taste like boot leather.

 

Link to comment
Share on other sites

If you want a sphere with 32 sides, you are probably better off not using a brush. Because of the way brushes are represented, very complex geometry can cause mathematical issues, and I wouldn't be surprised if such a complex brush gives some kind of problem (missing triangles after dmap etc).

Link to comment
Share on other sites

I could build the previous version.

But with this one I get this very early on:

map/MapModules.cpp:21:32:   required from here
/usr/include/c++/9/bits/unique_ptr.h:79:16: error: invalid application of ‘sizeof’ to incomplete type ‘map::ModelScalePreserver’
   79 |  static_assert(sizeof(_Tp)>0,
      |                ^~~~~~~~~~~
make[2]: *** [Makefile:5854: map/darkradiant-MapModules.o] Error 1
make[2]: Leaving directory '/home/john/Desktop/DarkRadiant/radiant'
make[1]: *** [Makefile:752: all-recursive] Error 1
make[1]: Leaving directory '/home/john/Desktop/DarkRadiant'
make: *** [Makefile:493: all] Error 2

 

Edited by PranQster
  • Like 1

System: Mageia Linux Cauldron, aka Mageia 8

Link to comment
Share on other sites

I might have found a major issue with Layers, so if you're getting close to a final version, please pause until I figure out what's going on.

In short, I'm seeing layers belonging to different maps showing up along with the layers of the map I'm working on.

Trying to create an example.

Link to comment
Share on other sites

I'm not providing example maps because you won't be able to examine *.darkradiant as the maps are edited according to the steps below.

After step 6, bring up a text editor and look at what DR has done with *.darkradiant.

It looks like, at step 7, orville.darkradiant retains the layers defined in archie.map (good), but when you rename them in steps 8 and 10, and save the map, a new Layers section gets added to orville.darkradiant, rather than having the current Layers definition replace the previous Layers section inherited from archie.map (bad).

I.e. it ends up looking like this:

    Layers
    {
        Layer 0 { Default }
        Layer 1 { Archie }
        Layer 2 { Walter }
    }
    Layers
    {
        Layer 0 { Default }
        Layer 1 { Orville }
        Layer 2 { Robert }
    }
    Layers
    {
        Layer 0 { Default }
    }

 

1. Create a new map.

2. Add an AI named Archie.

3. Add an AI named Walter.

4. Create layers "Archie" and "Walter".

5. Move Archie and Walter to their respective layers.

6. Save the map as archie.map.

7. Save the map as orville.map.

8. Change the "Archie" layer to "Orville".

9. Rename Archie to Orville and move him to the "Orville" layer.

10. Change the "Walter" layer to "Robert".

11. Rename Walter to Robert and move him to the "Robert" layer.

12. Save orville.map.

13. Open the previous map archie.map.

14. Look at the layers. They're Archie and Walter, as they should be.

15. Open the previous map orville.map.

16. Look at the layers. They're Archie and Walter, but they should be Orville and Robert. orville.darkradiant looks like the lines in the highlighted section above.

 

It looks like there's some integrity problem with saving/recalling layers.

I can't say when this first showed up, but I never saw this prior to this round of beta versions.

I also had a situation where, when I was switching maps, the layers changed to those of a map unrelated to what I was working on.

Since this appears to have been going on for a while, and I've been editing several different WIPs over the past week or so, I now have to unravel my layer settings. If I'm right about previous Layer definitions not being replaced, this might be as simple as removing everything prior to the latest definition. If somehow they've become tangled, it's going to be like unraveling a plate of spaghetti. 

 

So I'm stopping work until this is understood (and fixed).

If this is a bug (and I'm not just seeing things), it will have affected any mappers using layers, for as far back as when the bug was introduced.

 

 

 

 

 

 

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • Ansome

      Finally got my PC back from the shop after my SSD got corrupted a week ago and damaged my motherboard. Scary stuff, but thank goodness it happened right after two months of FM development instead of wiping all my work before I could release it. New SSD, repaired Motherboard and BIOS, and we're ready to start working on my second FM with some added version control in the cloud just to be safe!
      · 0 replies
    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
×
×
  • Create New...