SlickEdit Community
SlickEdit Product Discussion => SlickEdit® => Topic started by: rowbearto on November 01, 2021, 05:35:20 PM
-
Look for se_build_window_issue.tgz in support and see the README file as well as the other files.
-
Try turning on "Show VSLICKERRORPATH in build window" (Tools>Options>.Editing>General). So far, all I can tell is that this is messing up the cursor location. I'm still looking into this.
Changing this option won't effect catting this log file. Your logfile already has output based on hiding the VSLICKERRORPATH.
-
I have found a bug that can occur if you hide certain build window lines like VSLICKERRORPATH. This will be fixed in 26.0.1. It's rare but your example is the perfect test case for it. Thanks
I'm not sure if this is the only problem you are hitting. After you turn on "Show VSLICKERRORPATH in the build window", post if you are still having any problems.
-
Setting "Show VSLICKERRPATH in build window" seems to resolve the issue so far, haven't seen the issues again. I'll keep using this setting and see if anything new pops up.
Thanks!
-
It happened again this time with "Show VSLICKERRPATH" set to "ON".
Look for logbug.tgz on support. See the README file there for more information about the 2 different log files I provided.
-
Still looking into this one. At the moment, it looks like it has something to do with processing of backspace under certain circumstances. You have a ton of backspaces in this test case.
-
Built new installer to fix this:
http://support.slickedit.com/outbound/2600/se_26000006_linux64.tar.gz (http://support.slickedit.com/outbound/2600/se_26000006_linux64.tar.gz)
-
Thanks Clark! Downloading now and will install it. I will let you know if there are still issues.
-
Thanks again for the really good test case
-
It happened again even with the installer you provided.
Look for buildlog.tgz on support. See its README file.
-
These problems are due to long lines messing up scrolling. I've fixed this for v26.0.1. Hard to say if there are any other problems going on but I can't reproduce any more problems with my fix.
-
Are your fixes in 26.0.1 on top of what you provided in the special installer (post in this thread dated Nov 17)? There are more fixes besides that special installer?
If not then I'm also running with your same fixes yet the problem reproed.
-
The fixes you already have are merged into 26.0.1. You don't have the long line handling fix.
-
I still see the issue in 26.0.1.
I uploaded to support see: buildlog-26.0.1.tar.gz
-
So far, I'm not able to reproduce these problems. There must be a very specific boundary condition occurring.
Are you able to reproduce this problem by doing this in the process buffer:
cat se_build.log
-
Unfortunately it doesn't happen when I do "cat se_build.log" :(
How to proceed?
-
I'm going to try to come up with a way to record/play back what's going on the process buffer. Not sure if it's reasonably doable.
-
Thanks!
When I do the real build it is slower than catting the build log, don't know if that means anything.
I also notice these <SOH> keep getting added 1 at a time during the real build when it happens.
-
I was able to get rid of all the backspace characters in my log by setting TERM to xterm. It was defaulting to "dumb" before.
Even with this improvement to get rid of all the backspace characters I still did see this issue with <SOH> characters and my colored prompt not colored. I didn't save the log that time, will try to save it next time and see if it reproduces.
-
I wasn't able to come up with a record/playback algorithm. Code is way too complicated. I put together a special installer with some good debug generation. Debug info is stored in user.cfg.xml. When you start SlickEdit, it clears the previous debug info. A ton of debug info is generated. It's best to start SlickEdit, run a test case that fails and exit.
http://support.slickedit.com/outbound/2601/se_26000100_linux64_build_dbg.tar.gz (http://support.slickedit.com/outbound/2601/se_26000100_linux64_build_dbg.tar.gz)
Just run this debug version when you want to generated debug info for us to look at. Otherwise, run the normal 26.0.1 installer.
If you want, you can keep all those nasty backspaces if that helps reproduce a problem. It is possible there are still are multiple problems.
-
Thanks. Trying it now.
I will try to reproduce with this debug load, it doesn't always happen.
EDIT: I see you wrote debug info is in user.cfg.xml
-
No luck reproing it so far today. But all I'm doing is retrying builds over and over. I think it happens when I'm using SlickEdit for other things while a build is ongoing. I won't be doing that again until I return from vacation next year - so I may not have the debug info until then.
-
This isn't as easy for you to reproduce as I thought. I suspect there's a specific timing involved to produce the right border condition.
-
I was able to reproduce this with your debug version of SlickEdit. I saved the user.cfg.xml file, before/after closing SlickEdit. Hopefully it has the debug information you need.
Look for buildlogd.tar.gz on support.
-
I have found a problem. Hopefully it is THE problem. SlickEdit maintains a bookmark for the process buffer so it knows where to insert text. This bookmark is supposed to track the line number (and column) which is used to scroll cursor positions for all windows viewing this buffer. This bookmark line number is getting messed up when a long line is inserted. When this happens, SlickEdit will no longer be able to properly scroll cursor positions. Hopefully, this is the last problem. In any case, there's no point in me looking for another bug until this one is fixed.
I'll post when I've a fix for this.
-
Darn. There's a bug in the debug output. I need to output the line data differently. Otherwise, debugging your build output which has long lines is impossible.
I've built a new installer which fixes the debug generation.
http://support.slickedit.com/outbound/2601/se_26000100_linux64_build2_dbg.tar.gz (http://support.slickedit.com/outbound/2601/se_26000100_linux64_build2_dbg.tar.gz)
-
I'm running the new debug version now. When the problem strikes again I will provide you the debug data.
-
Happened again, this time with your latest debug installer.
It was too big for the support site, sent a download link to sstamp.
I had the Build(.process) window open when I did this build, not sure if that has anything to do with it or not? That window also didn't keep scrolling down, only showed the start of the build, while the build tool window did seem to scroll.
-
I'm seeing a \1 getting added in our xterm coloring function but I can't figure out why this is happening. It looks like a bug for sure. I've created another installer to give me more debug information in this function.
http://support.slickedit.com/outbound/2601/se_26000100_linux64_build3_dbg.tar.gz (http://support.slickedit.com/outbound/2601/se_26000100_linux64_build3_dbg.tar.gz)
Please give this installer a try and reproduce this again.
-
I reproduced it with your latest installer.
Look for buildlog4.tar.xz on support.
Notice I used xz compression to make it less than 50M so I could upload to support site.
To decompress it:
tar xvf buildlog4.tar.xz
My user.cfg.xml file is now 908MByte. How to make it smaller and get rid of old debug info?
-
Go back to running the non debug version of SlickEdit. I’ll let you know what I find. Removing the debug requires manually editing user.cfg.xml and deleting the debug profile. Can’t remember the exact profile name.
-
SlickEdit non-debug version seems very slow to me now, blocks often. Was wondering if it could be due to the large user.cfg.xml file with the debug info?
Would be interested in knowing how to remove all the debug info and see if this is the cause of my slowdowns?
-
I just got rid of the <misc.build_debug> section of user.cfg.xml. It is now 295K instead of close to 1Gig.
Hopefully this blocking will go away...
-
Here is the first bug. Easy for me to locate because the <after_color_out_char1_not_here> element is generated only if there is a bug.
47: -- ENABLE_...
48:
]]>
</in_buffer>
<in_insert>
<![CDATA[-- Configuring done
]]>
</in_insert>
<before_color linenum="48" lineofs="0"/>
<before_color_in_pending_text/>
<before_color_in_mark linenum="49" lineofs="0"/>
<after_color_out_line linenum="94" lineofs="0"/>
<after_color_out_char1_not_here linenum="94" lineofs="0"/>
<after_color linenum="48" lineofs="0"/>
<before_scroll_mark linenum="49" lineofs="0"/>
<before_scroll_buffer>
Notice that this file has around 48 lines (probably 49 lines) coming into SlickEdit's xterm coloring function. I say around 48 lines because the <in_insert> text has been inserted already but there's not another buffer output element before the xterm coloring for us to see the exact buffer contents. Then after coloring we see <after_color_out_line linenum="94" lineofs="0"/>. This should be impossible. No way the build buffer has 94 lines. This is somehow related to this bug and why the \1 byte is not being removed.
I had to add a lot more debug into SlickEdit's xterm coloring function to further investigate this. Since this next xterm coloring function is generating a lot more debug, I've had to remove some other debug because this stuff is getting crazy large as you've noticed.
Here's installer #4:
http://support.slickedit.com/outbound/2601/se_26000100_linux64_build4_dbg.tar.gz (http://support.slickedit.com/outbound/2601/se_26000100_linux64_build4_dbg.tar.gz)
I'm hoping that even if I can't quite understand what is going wrong this time, maybe I can do a mini playback and be able to trace the problem (assuming the problem isn't random). If I had to guess, it seems like the buffer being processed by the xterm color function is getting changed to another buffer. If this is happening, I've got a lot more debug checking for this happening to narrow down where it's happening.
-
I will try it.
Maybe you would be able to reproduce this if you made a colored prompt like mine, you can extract it from my logfile, and make it a prompt using a bash shell in SE - set PS1 to it.
Then stay in this bash shell and do whatever builds you do (such as SlickEdit) in there, then you would repro it? Keep that as your shell with colored prompt, maybe you'll hit this issue like I do.
-
My builds are pretty simple. I don’t think a colored prompt would be enough. I do run sgrep in the build window all the time. It outputs a lot of color but I never have any problems.
-
Is there an easy way for you to generate the debug into a different file than user.cfg.xml?
Having the large user.cfg.xml slows down using SlickEdit significantly.
After I removed the debug I got a significant speedup in SlickEdit.
I don't know exactly when this issue may hit. I may need to use the debug SlickEdit for a while before it hits, and it will get slower and slower as user.cfg.xml gets bigger, and this will make it harder to use.
-
I’ll put something together. It will have to write the xml debug file on exit for performance and simplicity. The config system is a fancier cache.
-
Here's installer #5:
http://support.slickedit.com/outbound/2601/se_26000100_linux64_build5_dbg.tar.gz (http://support.slickedit.com/outbound/2601/se_26000100_linux64_build5_dbg.tar.gz)
Start up should be fast. Exit could be slow when writing a huge XML file.
-
Thanks. Which xml file will have the debug information?
-
build-debug.xml. Sorry, forgot to tell you.
-
I captured the issue with debug installer #5.
Look for buildlog5.tar.xz on support.
-
Thanks. I'm seeing the same problem but I've had to put in more debug closer to where the line number is somehow going weird. This installer will display a "say" debug message which pops up a window and tells you to send in your debug file when this bug occurs. You may not be seeing a bad prompt yet but that really doesn't matter. That's just an additional bad side effect.
Here's installer #6:
http://support.slickedit.com/outbound/2601/se_26000100_linux64_build6_dbg.tar.gz (http://support.slickedit.com/outbound/2601/se_26000100_linux64_build6_dbg.tar.gz)
Sorry this is taking so long. The code doesn't look very complicated but I can't explain/understand why the line number just suddenly goes wonky. The previous debug was around code that was more complicated that I thought would be more likely to be the cause of the line number going wonky. This time, I've put debug in earlier around pretty much every simple statement. The debug info indicates that the file is not getting switched out which could have explained the sudden wonky line number.
-
Not sure if I caught it or not, but look for buildlog.tar.xz on support.
The debug version went haywire, there was a stack which you can see in the stack.log.
I figured I'd capture the debug output, but not sure any real problem in there.
I have noticed occasionally that the debug version runs out of memory and I have to restart it. That may have happened here, I'm not sure.
-
The bug I'm looking for didn't happen here. Search for "after_color_out_char1_not_here" in build-debug.xml. That's what I'm looking for. This latest installer is supposed to display a "say" debug window when that element is output. You may just be having problems due to running out of memory. You may need to restart to avoid running out of memory.
I did make a fix in this last build. However, the fix I made had to do with how backspace is handled and in the last debug file, there weren't any backspace characters.
-
Prior to the latest build with the fix I put in, you were able to get this "after_color_out_char1_not_here" bug to happen fairly easily. Now, you haven't been able to make this happen. Is this an accurate assessment?
-
Yes I have not been able to reproduce the issue. I don't see your "say" statement or the <SOH> with your debug load. I have done many builds I would have expected to see it by now.
-
Here's installer #7:
http://support.slickedit.com/outbound/2601/se_26000100_linux64_build_fix_2022_02_02.tar.gz (http://support.slickedit.com/outbound/2601/se_26000100_linux64_build_fix_2022_02_02.tar.gz)
This installer has no debug in it but has the same fix that was in the last debug installer. The latest hot fixes are rolled into this installer. That just means you don't need to install the latest hot fix build unless it occurs after the date this installer was built.
-
Thanks. I will go ahead and use installer #7. I stopped using the debug load because it would run out of memory. Sounds like installer #7 won't run out of memory since debug is removed.
I didn't notice there was a hotfix for 26.0.1. I usually get a message about new hotfixes because I am subscribed to:
https://community.slickedit.com/index.php/topic,6567.0.html
But looks like that thread was not updated when new hotfix was available.
-
I just got some of the <SOH> or \1 with the installer #7. So looks like the issue is still there. I changed which build I'm doing today. I will go back to using your last debug load see if I can catch it.
-
Ok. Switching back to the previous installer (#6) will provide the debug I need.
-
Unfortunately for the past few weeks I haven't done much coding. But with a few days of usage it seems that the issue does not reproduce with the debug installer (#6), but it does reproduce with installer #7.
Furthermore using installer #7 I observed it happening even without sshing into my build machine and using the default se shell.
I think something in installer #6 is preventing the problem from occurring. Maybe another debug installer is needed to track this down?
-
Only difference is no debug generation. I’ll double check.
-
I readded the debug.
Here's installer #8:
http://support.slickedit.com/outbound/2601/se_26000100_linux64_build8_dbg.tar.gz (http://support.slickedit.com/outbound/2601/se_26000100_linux64_build8_dbg.tar.gz)
-
It doesn't repro with installer #8, but it does repro with installer #7.
I think whatever debug you added between installer #5 and #6 is causing the issue to not occur.
-
The debug must change the timing. It’s just generating xml data in memory which should be fast.
-
FYI: Still seeing this issue in 26.0.2 with Patrick's commit in: https://community.slickedit.com/index.php/topic,18828.msg74731.html#msg74731 which has build date May 9, 2022.
-
It is happening quite often, kind of annoying. When I want to manually enter a command I have to manually remove the <SOH>. It happens without sshing in first (although my build script does do ssh).
Is there another way to add debug that could not make the problem go away?
-
How about I build an installer that generates the debug BUT doesn't write the data out unless a problem is detected? In addition, the data will need to truncated from time to time since the data generated can be very large.
I'm guessing the debug data changes the timing and this bug is DEFINITELY dependent on timing. It could be a compiler code generation bug but I haven't seen one of those in a very long time.
-
OK. I thought I remembered from a past post that you were writing xml (to a file?) when bug is detected and that changes the timing? Maybe just save a few global variables when bug is detected to not change the timing much? Then write the xml later? Maybe this is already what you are proposing?
-
FYI I'm using Patrick's commit: https://community.slickedit.com/index.php/topic,18828.msg74731.html#msg74731 which has build date May 9, 2022.
I'm also using Qt5 version.
Maybe something with this commit makes it happen more?
-
It’s just a timing dependent problem.
-
Here's a new Qt5 installer of 26.0.2 with debug and the mods I thought of.
http://support.slickedit.com/outbound/2602/se_26000201_linux64qt5-2022-06-03.tar.gz (http://support.slickedit.com/outbound/2602/se_26000201_linux64qt5-2022-06-03.tar.gz)
-
Thanks so much Clark! I will try it out.
Will it still fill up memory and I have to eventually exit it because consuming too much memory?
Or did you take care of that? You mentioned truncating the data in a previous post.
-
There is truncation in this one. If memory gets too large let me know and I’ll truncate it more. I shouldn’t need that much history as long as you exit when you get a debug message telling you to exit because a bug was found.
-
After firing it up and doing a few builds it crashed during a next build.
Look for crash_2022_06.tar.xz on support for the core dump file and user.cfg.xml
-
Messed up on truncation. Try this Qt5 installer of 26.0.2:
http://support.slickedit.com/outbound/2602/se_26000201_linux64qt5-2022-06-05.tar.gz (http://support.slickedit.com/outbound/2602/se_26000201_linux64qt5-2022-06-05.tar.gz)
This installer has more truncation.
-
Unfortunately it is not reproducing :( Did you add something else besides debug, or only debug?
-
Besides debug, there is an additional fix but this fix was also in the build that Patrick made for you for Python.
-
FYI: I am seeing this issue in 26.0.3.1 build date June 30. I see the <SOH> doing a build without even sshing in.
-
Here's a process buffer debug build for 26.0.3 that truncates quite a bit to reduce the size of the data:
http://support.slickedit.com/outbound/2603/se_26000301_linux64qt5-2022-07-14-process-dbg.tar.gz (http://support.slickedit.com/outbound/2603/se_26000301_linux64qt5-2022-07-14-process-dbg.tar.gz)
I'm still hoping we get some debug data for this. With more truncation, maybe the timing won't be thrown off as much.
-
Still seeing this issue in v27 beta3. I didn't do much building in v26.0.3 past few months so not sure if I didn't catch it with the debug version due to not using it, or if it really wasn't caught with the debug version. I did start doing builds again today.
-
I'll build a debug version once v27 is finished.
-
I think I start seeing this after I open the process buffer and move around in it, but I'm not sure. I haven't tried to systematically repro it this way (don't have time) but I was trying to observe what I do just before the <SOH> start coming out. I typically open process buffer by executing below macro (tied to right clicking in Build tool window at the line of an error in the small build window):
// https://community.slickedit.com/index.php?topic=16731.new;topicseen#new
_command void goto_editor_window_from_build() name_info(',')
{
int pl = p_line;
edit ("+b Build (.process)");
goto_line(pl);
}
I also see that the Build Tool window menu item of "Send output to editor window" uses 'toggle-process-tab-output'
Is there any possibility that using
edit ("+b Build (.process)");
Instead of
toggle-process-tab-output
and then jumping around in the big process buffer looking at things and searching
Could be causing these <SOH> characters to come out on the build window sometime after using the edit() function?
Note: This happens even if I never ssh into the build server first from the Build window. I've been avoiding the ssh and I still see these <SOH> in my build after a while.
-
I think this happens after I press Ctrl-End in the .process buffer while a build is ongoing. Sometimes I'm looking at one thing in the .process buffer that happened during early stages of the build and it isn't scrolling as I'm in early part of log while build is ongoing. Then when I'm done I want to see the build scrolling so I press Ctrl-End to make the buffer scroll. I do this in the process buffer editor window and in the tool window. To get the build log into the editor window I use goto_editor_window_from_build() from my last post. I have been refraining from doing Ctrl-End and I don't see these <SOH>. A short time ago I did Ctrl-End and then I did start seeing the <SOH> shortly afterwards.
-
I think I've found how to reproduce this issue.
Open the process buffer with:
edit ("+b Build (.process)");
Don't have checked in the build window: "Send Output to Editor Window"
Do a bunch of builds while you have the process buffer as an editor tab. Perhaps even do Ctrl+Home in the .process editor tab before a build.
Do this enough times and you will like see the <SOH> in the build output.
It is still happening for me in 27.0.1 on Linux x64.