Spill file I/O error

[curtiswren]

I’ve had an error window pop up a few times while using the beta 3 that says:

Spill file I/O error.
The spill file is currently set to /tmp/.
 To change the location of the spill file, go to Tools > Options >Application Options > Virtual Memory.

I haven’t seen this with any version prior to 2023. Unfortunately, I don’t have a way to reproduce this. I think in the latest case, I had just done a version control commit (git). If I hit the retry button, it just pops the window back up each time. If I hit cancel, slickedit crashes.

[Clark]

Make sure you have enough disk space

[curtiswren]

Looks like it’s a dedicated device with 16G. Is that big enough?

Thanks

[Clark]

Sounds big enough as long as you're not editing any really large files (like 1GB or more).

Doesn't sound like a disk space problem. You could prove that it's not a disk space problem by editing a large file (say 100MB) and doing a search and replace which replaces one occurrence for every line in the file. That way, it hits every block requiring it to be swapped out. That will require more than 100MB of disk space. Typically programmers edit small source files which in total don't add up to much.

In any case, keep any eye on it.

[curtiswren]

I just had it happen again. I checked /tmp at it was only 3% full. Hitting retry after checking /tmp just keeps bringing up the same dialog. Hitting cancel crashed slickedit.

All the files I was working on were pretty small. I created a test file around 100MB as you suggested and did the search/replace and it worked without issue.

Anything else I can try? Would core file help?

Thanks

[Clark]

What platform are you on? I see you have a previous post mentioning Linux. If you're on Linux, you could try the Qt 5 installer.

The Linux 64 Qt 5 installer is here:

http://support.slickedit.com/outbound/2800/se_28000003_linux64qt5_beta3.tar.gz

[Clark]

What language types do you edit?

[curtiswren]

Yes, we’re on Linux. We’ll try the Linux 64 Qt 5 installer.

95% of the time we’re editing c++. We have a few small scripts, sql, config files etc.

[curtiswren]

Just had another one of these errors with the Linux 64 Qt 5 installer version.

[Clark]

Definitely not a Qt thing then.

What language type were you editing when you got this error?

Please post your user.cfg.xml. That way I can check what features/settings you're using.

[JeffB]

I've been seeing this off-and-on as well.  Mostly c, yaml, python files.  Plenty of disk space and the spill files are written to a separate directory (just for spill files).  I've also closed all vs instances wiped the directory.  After restarting several instances, and only 3-5 spill files, which weren't very big, I got the errors.

On a side-note, I have a 1M yaml file that makes vs grind to a halt trying to search.  I have a feeling it may be related.

[Clark]

I've been seeing this off-and-on as well.  Mostly c, yaml, python files.  Plenty of disk space and the spill files are written to a separate directory (just for spill files).  I've also closed all vs instances wiped the directory.  After restarting several instances, and only 3-5 spill files, which weren't very big, I got the errors.

On a side-note, I have a 1M yaml file that makes vs grind to a halt trying to search.  I have a feeling it may be related.

What was the language type of the current/active file you were editing when the Spill I/O error occurred? I'm wondering if this is specific to a particular language or setting.

Please post your user.cfg.xml.

[JeffB]

I don't remember exactly what I was doing (or which instance of vs I was using) when this happened.  I uploaded my user.cfg.xml file with Case# "ClarkSpillFile"

If it happens again, I'll try to get more info.

[Clark]

One thing that might help is to debug vs with gdb when this Error message box is displayed:

Code: [Select]

sudo gdb -p <slickedit-pid>
Then invoke the "where" command to display the stack and post it here.

[JeffB]

OK.  I'll try that if it happens again.  BTW, the extremely long delay searching in large (600k-1.1M) YAML file was due to "Incremental Search".  When just doing a regular find (ie. w/o "Incremental Search" box checked on the full-sized find dialog), there is no delay.  May not be related to the Spill file.