Topics

Odd messages and crash on V5.2.0 #window-size


Rob Pearce
 

Hello all,

First, thank you for all the work you've done in creating XTrackCAD - it's really useful.

I've just installed V5.2.0 from the Linux shell script, currently in a temporary location for testing before committing to replace my V5.1.2a install. Mostly it's looking great. However, I noticed after one run that I got several copies of:

Temp draw in Main Mode. Contact Developers. See gtkdraw-cario.c:227

in the shell that I ran it from.

Having seen that, some time after closing the session, in fact, I ran it again. This time it failed to start, with the following printout:

xtrkcad: malloc.c:2379: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed.
Aborted

I tried again and it appeared fine, so nothing I can re-create for a bug report. I just thought I should mention it somewhere...


Cheers,

Rob


Dave Bullis
 

The temp draw message can occur if you're resizing the window while it's redrawing.  It's a minor preformance issue that's on my list.
The assert is due to memory corruption below us somewhere.  Looks like its non-reproducible unfortunately
I can't see that there is a connection.

Thanks for the note

Dave


Rob Pearce
 

On 01/12/2020 14:32, Dave Bullis wrote:
The temp draw message can occur if you're resizing the window while it's redrawing.
Right, and it does seem to constantly re-draw while I re-size the window. At least it now starts at a moderately sensible size (v5.1.2 used to spread a third of the way onto the second monitor but not full-width) and appears to re-size smoothly (v5.1.2 used to lag behind the cursor and I had to joggle the mouse for it to catch up).


Adam Richards
 

Rob,
The values of window size and position in the config file should work now at startup, so you can try to fix them at something you want. 

The new resize uses a pause mechanism that will only redraw the layout if the mouse pauses for a large fraction of a second (which is obviously true at the end of the resize operation).  So actually, the faster you move the mouse to what you want, the less drawing there will be. 

 Adam


Rob Pearce
 

On 02/12/2020 02:19, Adam Richards wrote:
The values of window size and position in the config file should work now at startup, so you can try to fix them at something you want.
Do you mean it should remember the last position and size, or do I have to manually edit them? Does that include coping with dual screen?

Cheers,

Rob


Adam Richards
 

Rob,
Yes - it will be recorded, but more importantly it will be used at startup (subject to restrictions below).. 

Dual screen support (I can speak for GTK on Mac here, because that is what I am most familiar with) is really single-screen because the OS presents a single virtual screen that covers both screens.  The application is not presented with information that allows it to work out what to do - the original idea is that the OS should handle all this - which works OK for native apps, but with an X11 app, the OS sees it as a window of the X11/XQuartz app which is managing the app within an app. This makes it tricky because when one screen goes away, or the user redistributes them, the positions (and sizes) are all "off" and the only evidence is that the screen size mysteriously changed.  If there is a lack of a prior second screen, the x,y may be off-screen in fact, or so close to an edge that it might as well be. What the code attempts to do is to ensure that the app is actually visible within what it is told when it asks for the screen size. 

On Linux, the situation is different. The user has to take action to cope with screen changes, as I read Ubuntu they have to scan to find new screens and tell the OS what to do with them. In general, it seems from my reading that Linux (especially at GTK2 level) is pretty hard to manage dynamic screens with, especially in combinations with different DPI and real-estate.  A fair amount of OS config twiddling seems to be needed just to get the desktop extended. 

On Windows, I don't know. 

All this to say that it may be that if you are trying to manage between two different screen setups and don't wish to spend time redistributing when changing between them, it is possible to fix the positions per setup by altering the config file using a script for instance before starting up.

-----

In GTK3 we have the ability to try to build with native OS backend support, in which we may be able to simply delegate this all to the OS.  About a year ago I had that working for Mac, but there still seemed to be some things that didn't work as well as I would have liked in the UI in general (although window position and sizing seemed OK) so I mainly concentrated on getting the GTK3 UI complete in X11 mode. Then V5.2 intervened.  

Adam


On Wed, Dec 2, 2020 at 6:02 AM Rob Pearce <rob@...> wrote:
On 02/12/2020 02:19, Adam Richards wrote:
> The values of window size and position in the config file should work
> now at startup, so you can try to fix them at something you want.

Do you mean it should remember the last position and size, or do I have
to manually edit them? Does that include coping with dual screen?

Cheers,

Rob








--
Adam Richards


Rob Pearce
 

On 02/12/2020 15:52, Adam Richards wrote:
On Linux, the situation is different. The user has to take action to cope with screen changes, as I read Ubuntu they have to scan to find new screens and tell the OS what to do with them. In general, it seems from my reading that Linux (especially at GTK2 level) is pretty hard to manage dynamic screens with, especially in combinations with different DPI and real-estate.  A fair amount of OS config twiddling seems to be needed just to get the desktop extended.
I am running Linux. The screen setup can be controlled as required, but the OS doesn't try to second-guess you and most window managers don't provide a GUI for it. But that's fine - I have a desktop with two screens and I never move them so why would I need a GUI to change something that never changes? If I regularly plugged my laptop into a second screen then I'd have more to say on the dynamic screen situation but I don't recall it being a big problem.

My experience with V5.2.0 so far is that it usually opens with the main window full width of the left hand screen (but not consistently full height) and the map window on top of it. This is not how I had it when last run because I always move the map window to the right hand screen. But it's better than V5.1.2 used to do.


Adam Richards
 

As I recall, the window settings are not saved until an actual save or program close. 


Rob Pearce
 

On 01/12/2020 14:32, Dave Bullis wrote:
The assert is due to memory corruption below us somewhere.  Looks like its non-reproducible unfortunately
I'm now getting this assert every time, since installing to a real location (/usr/local - although I then had to move the /usr/local/share/xtrkcad into /usr/local/lib for it to be found, which I consider a bug in the install)

It's so persistent that the only way I've actually managed to get xtrkcad to run is within valgrind. Here's the output of that:

rob@isaiah ~ $ valgrind xtrkcad
==7654== Memcheck, a memory error detector
==7654== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==7654== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==7654== Command: xtrkcad
==7654==
/usr/share/themes/MurrinaCandido/gtk-2.0/gtkrc:84: Murrine configuration option "gradients" is no longer supported and will be ignored.
/usr/share/themes/MurrinaCandido/gtk-2.0/gtkrc:84: Murrine configuration option "highlight_ratio" will be deprecated in future releases. Please use "highlight_shade" instead.
/usr/share/themes/MurrinaCandido/gtk-2.0/gtkrc:85: Murrine configuration option "lightborder_ratio" will be deprecated in future releases. Please use "lightborder_shade" instead.
==7654== Conditional jump or move depends on uninitialised value(s)
==7654==    at 0x25D8C0: wListFindValue (list.c:166)
==7654==    by 0x217877: ParamRegister (param.c:1132)
==7654==    by 0x17FDBB: InitCmdDraw (cdraw.c:2994)
==7654==    by 0x161C92: CreateMenus (misc.c:2578)
==7654==    by 0x161C92: wMain (misc.c:3023)
==7654==    by 0x15AA6B: main (main.c:83)
==7654==
==7654== Invalid read of size 8
==7654==    at 0x211F02: GetScaleTrackGauge (misc2.c:247)
==7654==    by 0x1CFFFB: GetTrackCompatibility (cturnout.c:273)
==7654==    by 0x21965E: SetParamFileState (paramfile.c:160)
==7654==    by 0x219FEB: ReadParamFile (paramfile.c:211)
==7654==    by 0x21A770: LoadParamFileList (paramfilelist.c:226)
==7654==    by 0x21AD04: ParamFileListInit (paramfilelist.c:449)
==7654==    by 0x1629E1: wMain (misc.c:3061)
==7654==    by 0x15AA6B: main (main.c:83)
==7654==  Address 0x7a7fb40 is 16 bytes before a block of size 26 alloc'd
==7654==    at 0x483777F: malloc (vg_replace_malloc.c:309)
==7654==    by 0x15B567: MyMalloc (misc.c:212)
==7654==    by 0x15B601: MyStrdup (misc.c:292)
==7654==    by 0x211B7F: AddScale (misc2.c:618)
==7654==    by 0x219A14: ReadParams (paramfile.c:373)
==7654==    by 0x21ACDC: ParamFileListInit (paramfilelist.c:442)
==7654==    by 0x1629E1: wMain (misc.c:3061)
==7654==    by 0x15AA6B: main (main.c:83)
==7654==
==7654== Invalid read of size 8
==7654==    at 0x211F22: GetScaleRatio (misc2.c:252)
==7654==    by 0x1B82E3: GetStructureCompatibility (cstruct.c:234)
==7654==    by 0x21967F: SetParamFileState (paramfile.c:160)
==7654==    by 0x219FEB: ReadParamFile (paramfile.c:211)
==7654==    by 0x21A770: LoadParamFileList (paramfilelist.c:226)
==7654==    by 0x21AD04: ParamFileListInit (paramfilelist.c:449)
==7654==    by 0x1629E1: wMain (misc.c:3061)
==7654==    by 0x15AA6B: main (main.c:83)
==7654==  Address 0x7a7fb38 is 24 bytes before a block of size 26 alloc'd
==7654==    at 0x483777F: malloc (vg_replace_malloc.c:309)
==7654==    by 0x15B567: MyMalloc (misc.c:212)
==7654==    by 0x15B601: MyStrdup (misc.c:292)
==7654==    by 0x211B7F: AddScale (misc2.c:618)
==7654==    by 0x219A14: ReadParams (paramfile.c:373)
==7654==    by 0x21ACDC: ParamFileListInit (paramfilelist.c:442)
==7654==    by 0x1629E1: wMain (misc.c:3061)
==7654==    by 0x15AA6B: main (main.c:83)
==7654==
==7654== Invalid read of size 8
==7654==    at 0x211F22: GetScaleRatio (misc2.c:252)
==7654==    by 0x1E6719: GetCarProtoCompatibility (dcar.c:609)
==7654==    by 0x21967F: SetParamFileState (paramfile.c:160)
==7654==    by 0x219FEB: ReadParamFile (paramfile.c:211)
==7654==    by 0x21A770: LoadParamFileList (paramfilelist.c:226)
==7654==    by 0x21AD04: ParamFileListInit (paramfilelist.c:449)
==7654==    by 0x1629E1: wMain (misc.c:3061)
==7654==    by 0x15AA6B: main (main.c:83)
==7654==  Address 0x7a7fb38 is 24 bytes before a block of size 26 alloc'd
==7654==    at 0x483777F: malloc (vg_replace_malloc.c:309)
==7654==    by 0x15B567: MyMalloc (misc.c:212)
==7654==    by 0x15B601: MyStrdup (misc.c:292)
==7654==    by 0x211B7F: AddScale (misc2.c:618)
==7654==    by 0x219A14: ReadParams (paramfile.c:373)
==7654==    by 0x21ACDC: ParamFileListInit (paramfilelist.c:442)
==7654==    by 0x1629E1: wMain (misc.c:3061)
==7654==    by 0x15AA6B: main (main.c:83)
==7654==
==7654== Invalid read of size 8
==7654==    at 0x211F22: GetScaleRatio (misc2.c:252)
==7654==    by 0x1E6930: GetCarPartCompatibility (dcar.c:1285)
==7654==    by 0x21967F: SetParamFileState (paramfile.c:160)
==7654==    by 0x219FEB: ReadParamFile (paramfile.c:211)
==7654==    by 0x21A770: LoadParamFileList (paramfilelist.c:226)
==7654==    by 0x21AD04: ParamFileListInit (paramfilelist.c:449)
==7654==    by 0x1629E1: wMain (misc.c:3061)
==7654==    by 0x15AA6B: main (main.c:83)
==7654==  Address 0x7a7fb38 is 24 bytes before a block of size 26 alloc'd
==7654==    at 0x483777F: malloc (vg_replace_malloc.c:309)
==7654==    by 0x15B567: MyMalloc (misc.c:212)
==7654==    by 0x15B601: MyStrdup (misc.c:292)
==7654==    by 0x211B7F: AddScale (misc2.c:618)
==7654==    by 0x219A14: ReadParams (paramfile.c:373)
==7654==    by 0x21ACDC: ParamFileListInit (paramfilelist.c:442)
==7654==    by 0x1629E1: wMain (misc.c:3061)
==7654==    by 0x15AA6B: main (main.c:83)
==7654==
==7654== Conditional jump or move depends on uninitialised value(s)
==7654==    at 0x1B8340: GetStructureCompatibility (cstruct.c:243)
==7654==    by 0x21967F: SetParamFileState (paramfile.c:160)
==7654==    by 0x219FEB: ReadParamFile (paramfile.c:211)
==7654==    by 0x21A770: LoadParamFileList (paramfilelist.c:226)
==7654==    by 0x21AD04: ParamFileListInit (paramfilelist.c:449)
==7654==    by 0x1629E1: wMain (misc.c:3061)
==7654==    by 0x15AA6B: main (main.c:83)
==7654==
==7654== Conditional jump or move depends on uninitialised value(s)
==7654==    at 0x1B8342: GetStructureCompatibility (cstruct.c:243)
==7654==    by 0x21967F: SetParamFileState (paramfile.c:160)
==7654==    by 0x219FEB: ReadParamFile (paramfile.c:211)
==7654==    by 0x21A770: LoadParamFileList (paramfilelist.c:226)
==7654==    by 0x21AD04: ParamFileListInit (paramfilelist.c:449)
==7654==    by 0x1629E1: wMain (misc.c:3061)
==7654==    by 0x15AA6B: main (main.c:83)
==7654==
==7654== Conditional jump or move depends on uninitialised value(s)
==7654==    at 0x1B8340: GetStructureCompatibility (cstruct.c:243)
==7654==    by 0x21967F: SetParamFileState (paramfile.c:160)
==7654==    by 0x21AA3A: UpdateParamFileList (paramfilelist.c:303)
==7654==    by 0x257198: ParamFilesChange (dprmfile.c:397)
==7654==    by 0x212878: DoChangeNotification (misc2.c:152)
==7654==    by 0x212878: DoSetScale (misc2.c:505)
==7654==    by 0x162A32: wMain (misc.c:3081)
==7654==    by 0x15AA6B: main (main.c:83)
==7654==
==7654== Conditional jump or move depends on uninitialised value(s)
==7654==    at 0x1B8342: GetStructureCompatibility (cstruct.c:243)
==7654==    by 0x21967F: SetParamFileState (paramfile.c:160)
==7654==    by 0x21AA3A: UpdateParamFileList (paramfilelist.c:303)
==7654==    by 0x257198: ParamFilesChange (dprmfile.c:397)
==7654==    by 0x212878: DoChangeNotification (misc2.c:152)
==7654==    by 0x212878: DoSetScale (misc2.c:505)
==7654==    by 0x162A32: wMain (misc.c:3081)
==7654==    by 0x15AA6B: main (main.c:83)
==7654==
==7654== Invalid write of size 4
==7654==    at 0x163F83: ReadBlock (cblock.c:446)
==7654==    by 0x237B40: ReadTrack (track.c:1442)
==7654==    by 0x20A375: ReadTrackFile (fileio.c:733)
==7654==    by 0x20AD46: LoadTracks (fileio.c:956)
==7654==    by 0x20B188: DoFileList (fileio.c:1010)
==7654==    by 0x1628DF: wMain (misc.c:3121)
==7654==    by 0x15AA6B: main (main.c:83)
==7654==  Address 0x6bd9168 is 0 bytes after a block of size 104 alloc'd
==7654==    at 0x483777F: malloc (vg_replace_malloc.c:309)
==7654==    by 0x15B567: MyMalloc (misc.c:212)
==7654==    by 0x1640AB: ReadBlock (cblock.c:445)
==7654==    by 0x237B40: ReadTrack (track.c:1442)
==7654==    by 0x20A375: ReadTrackFile (fileio.c:733)
==7654==    by 0x20AD46: LoadTracks (fileio.c:956)
==7654==    by 0x20B188: DoFileList (fileio.c:1010)
==7654==    by 0x1628DF: wMain (misc.c:3121)
==7654==    by 0x15AA6B: main (main.c:83)
==7654==
==7654== Invalid read of size 4
==7654==    at 0x164197: ReadBlock (cblock.c:471)
==7654==    by 0x237B40: ReadTrack (track.c:1442)
==7654==    by 0x20A375: ReadTrackFile (fileio.c:733)
==7654==    by 0x20AD46: LoadTracks (fileio.c:956)
==7654==    by 0x20B188: DoFileList (fileio.c:1010)
==7654==    by 0x1628DF: wMain (misc.c:3121)
==7654==    by 0x15AA6B: main (main.c:83)
==7654==  Address 0x6bd9168 is 0 bytes after a block of size 104 alloc'd
==7654==    at 0x483777F: malloc (vg_replace_malloc.c:309)
==7654==    by 0x15B567: MyMalloc (misc.c:212)
==7654==    by 0x1640AB: ReadBlock (cblock.c:445)
==7654==    by 0x237B40: ReadTrack (track.c:1442)
==7654==    by 0x20A375: ReadTrackFile (fileio.c:733)
==7654==    by 0x20AD46: LoadTracks (fileio.c:956)
==7654==    by 0x20B188: DoFileList (fileio.c:1010)
==7654==    by 0x1628DF: wMain (misc.c:3121)
==7654==    by 0x15AA6B: main (main.c:83)
==7654==
==7654==
==7654== HEAP SUMMARY:
==7654==     in use at exit: 15,118,701 bytes in 82,835 blocks
==7654==   total heap usage: 636,468 allocs, 553,633 frees, 118,409,407 bytes allocated
==7654==
==7654== LEAK SUMMARY:
==7654==    definitely lost: 202,335 bytes in 1,514 blocks
==7654==    indirectly lost: 1,260,348 bytes in 22,392 blocks
==7654==      possibly lost: 377,300 bytes in 1,974 blocks
==7654==    still reachable: 12,220,774 bytes in 50,216 blocks
==7654==                       of which reachable via heuristic:
==7654==                         length64           : 4,560 bytes in 63 blocks
==7654==                         newarray           : 1,872 bytes in 37 blocks
==7654==         suppressed: 0 bytes in 0 blocks
==7654== Rerun with --leak-check=full to see details of leaked memory
==7654==
==7654== Use --track-origins=yes to see where uninitialised values come from
==7654== For lists of detected and suppressed errors, rerun with: -s
==7654== ERROR SUMMARY: 33 errors from 11 contexts (suppressed: 0 from 0)



Some of those look like real definite bugs in xtrkcad, which are usually the cause of such malloc assertions.


Adam Richards
 
Edited

The Scale related ones - 

Looks like we are trying to use currScale as an index when it hasn't been set (yet) and so is -1.  There are no guards on the value of the index in this situation, leading to a potentially negative memory offset. 

I suppose it is quite possible/likely that the parm files are being assessed for "fit" before the correct Scale has been read from the layout file...

The ReadBlock ones - 

This seems to be associated with the use of the blockTrack_da array.  It may be that the .max value is not being set initially.  It is a static. 

Attempted fix pushed. 

Adam 


Adam Richards
 

Found another Block issue (not allocating enough) - fix pushed.

Adam