Cannot create directory or file on CentOS v6.3 (Exception happens) #253
Comments
|
Please open a terminal window and run: Then create a file or dir in spacefm, and when spacefm exits, check the terminal to see what messages are there - thanks. |
|
Ok. I did it and here is the output from the terminal. I am getting an exception: (spacefm:15675): Gtk-CRITICAL **: gtk_entry_get_text: assertion `GTK_IS_ENTRY (entry)' failed (spacefm:15675): GLib-CRITICAL **: g_strchug: assertion `string != NULL' failed (spacefm:15675): GLib-CRITICAL **: g_strchomp: assertion `string != NULL' failed |
|
Thanks - odd that this isn't reproducible. Could you show me the output of: (That will tell me GTK2 or GTK3). Also, did you reconfigure what fields are visible in the rename dialog (Options button), or is everything at its default? (If changed, you might consider providing a screenshot as that dialog is complex). Also, are you right-clicking on the desktop, or in the file manager? Does it only occur when you right-click on an empty space and not on an existing file? Finally, what view mode are you using in the file manager (detailed, icons, or compact)? If you feel like it, a backtrace might be helpful (see BUILD DEBUG instructions in README), otherwise I'll look over the code and see if I can find where this is coming from. |
|
No, thank you for helping me get this going (: I am using GTK2 (show in Gnome Help – About screen). Verified with “spacefm –version” which outputs: I built manually using: Then, without making any spacefm configuration setting changes, I got the bug I posted when I ran spacefm. All settings were default. Then, afterwards, I tried troubleshooting a bit and All other spacefm settings are still default. Wasn’t using “rename” dialog. Failure (exception) is caused by both “New – File” and “New – Folder” commands. In any case, I used the default “Options” settings in the dialog and didn’t change anything. After reading your response, I tried to get some more info for you:
Then, I built the debug version of spacefm and generated the error from within gdb. Running spacefm from within gdb generates the following output on the gdb terminal: (spacefm:3027): GLib-CRITICAL **: g_strchug: assertion `string != NULL' failed (spacefm:3027): GLib-CRITICAL **: g_strchomp: assertion `string != NULL' failed Program received signal SIGSEGV, Segmentation fault. Then, I ran the backtrace and got the following. Looks like the problem is with the ptk_rename_file() function….. P.S. Is there a way to attach a text file in Github, instead of having to insert a long output like below? Albert (gdb) bt full #1 0x00000000004517aa in create_new_file (data=0xa48b80, create_new=2) at ptk/ptk-file-menu.c:2495 #2 0x000000000045180f in on_popup_new_folder_activate (menuitem=, data=) at ptk/ptk-file-menu.c:2513 #3 0x0000003865c0bb3e in g_closure_invoke () from /lib64/libgobject-2.0.so.0 |
|
IgnorantGuru, are you using a graphical IDE to debug the code? Which one? Eclipse? If so, do you have an Eclipse project config file that you can send me (ie. so that I can open the spacefm project in an IDE and then step through the code)? I can step back from the point of the exception, on my system, and then we can isolate what is failing on my system. It may be hard for you to isolate the problem without running on my actual system. The failure is happening at line #2754 in ptk-file-misc.c. str[0] faults because the "str" pointer is NULL (as can be seen in the backtrace. I would like to step through the code leading up to that point to isolate the failure. |
Change method used to get combo entry text due to inexplicable GTK_IS_ENTRY (entry) failed Test for non-null return string
|
It appears that this method for obtaining the contents of the template entry is failing for you - apparently that is the source of your 'GTK_IS_ENTRY (entry) failed' warning. Why that would be I can't say - that method for obtaining the entry from the combo box is documented. It's also used elsewhere in this dialog and in spacefm and has never caused a problem. Do you see a Template box in the new file dialog containing "Empty File" by default? At any rate, the crash was simply due to that returned string being NULL. I have changed the method for obtaining the entry contents, and also made it verify it has a non-NULL value. This should at least stop that crash. But it will be interesting to see if the templates work correctly for you, and whether you see any other entry warnings from this or other dialogs. Unlike this case, use of gtk_bin_get_child is sometimes required (eg for setting the entry's text). You can test my changes using the BUILD NEXT instructions in README.
What version is your gtk2 lib package? eg 2.24?
You can set the graphical su program to 'kdesu' and then set root's editor to 'gedit' (spacefm knows to run it as root).
Rename and new file/folder use the same dialog in a different mode.
You can use a gist, or just use pastebin. Thanks for the backtrace.
No. |
|
Also, you might use GTK_IS_COMBO_BOX() on mset->combo_template to see if it is in fact a valid combo box when the code gets to that section. eg: |
|
Any more info on this is welcome - eg any warnings still appearing with the next build. Still wondering why that mset->combo_template pointer appears to be going invalid. |
|
Sorry, this GIT editor does funny things sometimes. I thought this comment was posted a few days ago but I just realized that it must have timed out or something and not posted. Here is the old comment that didn't post: Yes, when executing the "New - File" command, I do see the "Template:" box in the dialog and it is set to "Empty File" by default. When I select the "New - Folder" command, I see the "Template:" box in the dialog and it is set to "Empty Folder" by default. The GTK2 Lib package version is v2.18.9-10 (x86_64). I am on a 64-bit system. Thanks for the info on gist and pastebin. Ok, I will compile and run the latest version (BUILD NEXT), later tonight, and tell you the results. Started doing this but need to configure my autoconf macro dir as part of the build... |
|
Got swamped with work these last few days. Will try and continue building your latest update and then give feedback ASAP, but it may take a few more days till I am free again to continue troubleshooting this. I was following the instructions to setup my environment for BUILD NEXT. I got as far as running "autogen.sh". I got the following warnings and wanted to resolve these before continuing. For all I know, these errors/warnings are causing my main/previous build (of the released code) from working (and causing the error I am getting with failure to create dir/files). So, I always try and be careful and fully understand/resolve any warnings/errors I get while building code. As you can see, the "autogen.sh" script is causing warnings/errors, with my build environment, related to macros. I have been reading up on "autoconf" usage and environment configuration but this stuff is tricky. Do you know how to fix the errors I am getting related to copying "codeset.m4", etc.., files to the autoconf macro directory? I started reading about "AC_CONFIG_MACRO_DIR", etc.., here: http://www.flameeyes.eu/autotools-mythbuster/autoconf/macros.html, but need to finish reading and absorbing what I really need to do and what is the best way to deal with these warnings/errors, keeping in mind that I want to also be able to use the same Linux system to build drivers and applications in the future. So, I want to take care of this stuff in the right way (not a cludge). If you have experience with this, and can explain to me what is the best way to deal with these warnings and setup my environment for future code builds, let me know (it will save me time). In particular, where is the best place to put the missing macros, and what is the best way to tell the make tools where to find these (in the general case)? I also need the "config.guess", etc.., files listed in a separate warning. Line #120 in the autogen.sh file is generating the first set of warnings. here is the command: Then, I am getting some additional warnings from libtoolize at line #135: Note: If you can help me get setup so that I can step through the source code in gdb (actually using real source files), then I can quickly tell you which line is causing the problem and let you fix it. I have already reviewed the entire ptk-file-menu.c file and understand it enough to be able to isolate the problem and direct you to the exact line which fails on my system. Bit, I have always used a graphical IDE in the past and need to refresh my memory on how to use gdb to step through real "C/C++" source files. Here is the autogen.sh terminal output: [server]$ ./autogen.sh processing . Please add the files Making ./aclocal.m4 writable ... |
|
Didn't mean to rush you, just wanted to make sure you and others knew that this doesn't appear to be fully resolved. Actually you can run ./configure in place of ./autogen.sh and I think that will work. I recommended autogen because the next branch can sometimes (rarely) be in a pre-autoconf state, but I didn't realize it would cause so many complications - I should revise that. No one has reported any problems with the next build though. As for those warnings, nothing there should be critical so safe to ignore them for this purpose. spacefm's build system is quite reliable if a little noisy. I have tried to clear some of those warnings but it led to unwarranted complications and investments of time, and some of those warnings I haven't seen, but doesn't look critical. If it configures and makes you should be good to go. Not sure how many are affected by this but it sounds like it may be related to gtk <=2.20 (a debian squeeze user also encountered it), although it would be odd that it wasn't reported until now. I'm wondering if mset->combo_template pointer is being corrupted. Thanks for the efforts. |
|
Actually, looking at it again I think maybe following gtk2.20 the gtk devs changed something in the combobox bin. I'd be interested to know if you're still seeing a warning but you may want to wait on any further debugging until I look into the possible gtk break. |
|
Ok, I just ignored the autogen warnings and ran the rest of the build, which completed ok. With this latest version, everything appears to work ok. Good job (:
I would like to help you isolate the exact line in the code that was causing the problem next, by stepping the code with gdb.... |
|
Thanks for the feedback. Do any warnings appear on stderr (run spacefm in a terminal) when using that dialog? Also, do the template functions work? For example, if you copy some assorted files to ~/Templates/ are they listed in the Template drop-down box? And if you select one, is the new file a copy of that file? |
|
Thank you for working on this (: I really like the multi-pane capability and will be happy when I can start using it. When I try and create a directory, it is created. Here is the terminal output: The following is output after I create a dir... TASK_COMMAND=mkdir '/data/software/SpaceFM/tmp' If I try and create another dir, the same above output happens again.... I exited SpaceFM and then reran it. When I try and create a file, here is the output after I initiate creating the file: Then, when I am in the file creation dialog, as soon as I select the template drop down box, I do see a file I placed in the ~/Templates dir called "template_test.txt". As soon as I select it, I get the following output in the terminal: Creating a new dir and selecting a dir template (~/Templates/tmp1/tmp2) correctly creates the new dir and the following is output on the terminal (no "Gtk-CRITICAL"): Let me know if there is anything else you want me to try. Over the next week, I will try and learn how to step through the source code and then I can help you isolate the exact line that is failing quick, if you haven't figured it out already.... |
|
This should now be fully corrected in d6001c7. It looks like the gtk < 2.24 compatibility define was either a typo or an oversight (it's very confusing what they did with the changes to combo boxes between gtk updates - one area where supporting multiple gtk versions is challenging). I haven't actually built this with gtk2.20 yet so if you could try the next branch and see if those warnings are cleared that would be helpful - thanks! Also note that the Template drop-down lists should have an entry (you can type in the box in addition to being able to select from the drop-down list), which they probably didn't have with gtk < 2.24 until now. Hence the warning. |
|
This is confirmed corrected elsewhere. |
|
FYI, also verified the latest v0.8.5-37 build with the #define fix in gtk2-compat.h. Looks like this fixes the problem and was the main issue. Now, in addition to files and dir's being created correctly without causing exceptions, there are no more errors/warnings output on the terminal when the dialog box and/or template box is invoked. Thank you very much IG for fixing this quickly. I am so happy I can start using SpaceFM now as my main file explorer. The only thing I may have to still use Nautilus for is to access Samba shares. It would be good if we add this functionality into a future version of SpaceFM. Can probably use the Nautilus source code as reference. P.S. Are you the main creator of SpaceFM? |
|
Thanks for the confirmation. As for samba shares, spacefm can mount these if udevil is installed, or if you use another method via a custom protocol handler. There are also some relevant plugins for browsing smb shares. Nautilus uses gvfs for this support, which is not a dependency of spacefm. I am the lead developer of SpaceFM, and its predecessor PCManFM-Mod. You can read the history here. |
|
Ok. Cool. Very cool! I will try udevil and check out the plugins. I am jazzed that SpaceFM can also be made to support network file systems (: I read the history and some of the documentation. Great job on the documentation. Looks like you guys have designed in some really good API's, and put a lot of thought into the SpaceFM architecture and extensibility. I like that it can be customized so much. |
|
Is there a way I can email you outside of this thread? I don't want to clutter it with irrelevant stuff. Maybe you can send me your email or point me at a thread for new features/stuff? I noticed that CentOS (my new favorite distro because of it's stability) is not in the supported packages section. Can I help you to build a CentOS binary (64-bit for starters) for distribution as a CentOS package? If so, can you give me some guidelines/tips/recommendations for doing this? On my current 64-bit CentOS system (Athlon), I always keep it updated with the latest updates (for the CentOS v6.3 build). As you know, CentOS mirrors RedHat RHEL releases pretty closely (except for some cosmetic stuff: logos, etc..). |
|
My email is here, but I already get too much email and thus am not very responsive. I prefer forum or blog discussions so others can read the same. You can find various resources on the homepage - there's also an irc channel and wiki, etc. You might also ask on a CentOS forum how to proceed with packaging spacefm/udevil. It's mostly just me developing this so I don't have time to get involved much in packaging, but you're certainly welcome to provide CentOS packages. You can add relevant info here yourself when it's available. Thanks for your interest. |
|
Ok, thanks for the info. Ok, I will look into making SpaceFM/udevil packages available for CentOS. Since CentOS’s claim to fame is binary compatibility with Redhat RHEL, I don’t think we can get it bundled into the statndard CentOS distribution unless I am able to convince Redhat to include it in their standard release (which is possible, I will also look into this). But, there are separate default repositories that work with CentOS and I will look into getting CentOS/udevil added to these repositories. Do you consider the current release of SpaceFM stable enough for mass distribution? I don’t think we should pursue this until it is stable. Do you have a QA/QC process that you go through for new “stable” releases of SpaceFM? If not, maybe I can help you set this up…. Albert |
|
Yes, SpaceFM is stable - particularly release versions (the master code branch). next branch is for pre-release testing. Thanks for the packaging! |
Cannot create directory (or file) on CentOS v6.3. When I "right-click" in an empty space and then select "New - Folder" (or "New - File"), the Create New Folder dialog pops up. Then, when I type in a new dir name, and select "Create", SpaceFM just exits! Selecting "As Root" doesn't help). I don't think permissions are a problem. I also tried creating a dir in the "/tmp" dir and it also exited. I have also tried running SpaceFM as a Superuser (sudo /usr/local/bin/spacefm), which runs but then it exits in the same way as when I run as a normal user!
Not sure what is going on here. Can someone help??? I really like SpaceFM especially because of the support for (4) panes. I have tried some other functions of SpaceFM (for instance deleting a dir) and they appear to work ok. I can run 1-4 panes no problem.
I am using the current build of CentOS v6.3 (kernel v2.6.32-279.19.1).
I have downloaded and built the master source code (IgnorantGuru-spacefm-0.8.5-0-ge6dd4b4.tar.gz). The same thing happens with v0.8.3. I have 25 yrs experience with software development! While building, everything looks ok. No obvious errors (once I resolved any missing dependencies).
This problem exists on both the v0.8.5 and v0.8.3 version of SpaceFM....
The text was updated successfully, but these errors were encountered: