I have a FUSE program in debug mode displaying a lot of debug messages
on the terminal.
After hours the program "freeze" and the terminal looks blocked.
The terminal don't react to key press, nor CTRL-C nor CTRL-Z

Using gdb, I get 31 threads, the 25 looks strange.
It looks to be blocking on a write() system call while displaying a
debug message to the terminal
Then I tried
# echo hello > /dev/pts/2
and it's blocking too !
Other pts on the same host don't block

How can a pts block ? Probably a problem with ssh or sshd. Using
strace, I can see both waiting on a select()
and not reacting to a key press or to the echo hello > /dev/pts/2. The
ssh client is running on a fedora 11

What next ?

I'm running fedora 14 on x64, but get exactly the same on a f14 i386.
I'm running the same test on centos-6 x64 just now


Regards
--
Alain Spineux * * * * * * * * * | *aspineux gmail com
Monitor your iT & Backups | *http://www.magikmon.com
Free Backup front-end * * * | http://www.magikmon.com/mksbackup
Your email 100% available | *http://www.emailgency.com
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Alain Spineux <aspineux <at> gmail.com> writes:

>
> I have a FUSE program in debug mode displaying a lot of debug messages
> on the terminal.
> After hours the program "freeze" and the terminal looks blocked.
> The terminal don't react to key press, nor CTRL-C nor CTRL-Z
>
> Using gdb, I get 31 threads, the 25 looks strange.
> It looks to be blocking on a write() system call while displaying a
> debug message to the terminal
> Then I tried
> # echo hello > /dev/pts/2
> and it's blocking too !
> Other pts on the same host don't block
>
> How can a pts block ? Probably a problem with ssh or sshd. Using
> strace, I can see both waiting on a select()
> and not reacting to a key press or to the echo hello > /dev/pts/2. The
> ssh client is running on a fedora 11
>
> What next ?
>
> I'm running fedora 14 on x64, but get exactly the same on a f14 i386.
> I'm running the same test on centos-6 x64 just now
>
> Regards

I would say take a look at pertinent info (from another terminal on that
machine):
$ w
$ ps aux |grep -i pts

Threads:
$ ps -eLf |grep -i pts
$ ps axms |grep -i pts
$ man ps # signals: PENDING or BLOCKED or IGNORED or CAUGHT
$ man select

JB


--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

On Wed, Oct 12, 2011 at 4:42 PM, JB <jb.1234abcd@gmail.com> wrote:
> Alain Spineux <aspineux <at> gmail.com> writes:
>
>>
>> I have a FUSE program in debug mode displaying a lot of debug messages
>> on the terminal.
>> After hours the program "freeze" and the terminal looks blocked.
>> The terminal don't react to key press, nor CTRL-C nor CTRL-Z
>>
>> Using gdb, I get 31 threads, the 25 looks strange.
>> It looks to be blocking on a write() system call while displaying a
>> debug message to the terminal
>> Then I tried
>> # echo hello > /dev/pts/2
>> and it's blocking too !
>> Other pts on the same host don't block
>>
>> How can a pts block ? Probably a problem with ssh or sshd. Using
>> strace, I can see both waiting on a select()
>> and not reacting to a key press or to the echo hello > /dev/pts/2. The
>> ssh client is running on a fedora 11
>>
>> What next ?
>>
>> I'm running fedora 14 on x64, but get exactly the same on a f14 i386.
>> I'm running the same test on centos-6 x64 just now
>>
>> Regards
>
> I would say take a look at pertinent info (from another terminal on that
> machine):
> $ w
> $ ps aux |grep -i pts

ps was freezing, I had to grep /proc/*/stat

>
> Threads:
> $ ps -eLf |grep -i pts
> $ ps axms |grep -i pts
> $ man ps * * * * # signals: PENDING or BLOCKED or IGNORED or CAUGHT
> $ man select


The problem is not solved but if I disable debugging, the terminal is
not "flooded" and application finish without blocking.

Thanks for answering.

>
> JB
>
>
> --
> users mailing list
> users@lists.fedoraproject.org
> To unsubscribe or change subscription options:
> https://admin.fedoraproject.org/mailman/listinfo/users
> Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
>



--
Alain Spineux * * * * * * * * * | *aspineux gmail com
Monitor your iT & Backups | *http://www.magikmon.com
Free Backup front-end * * * | http://www.magikmon.com/mksbackup
Your email 100% available | *http://www.emailgency.com
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Alain Spineux <aspineux <at> gmail.com> writes:

> ...
>
> The problem is not solved but if I disable debugging, the terminal is
> not "flooded" and application finish without blocking.
> ...

It's a guessing game and a lot to chew ... the app, FUSE fs, OS :-)
So, just a few random things.

OS:
===
Because of "After hours the program "freeze"...":
$ ulimit -a
$ cat /etc/sysctl.conf

Around the time your app gets locked, any messages in /var/log/messages ?
$ ls -al /dev/pts/*

FUSE:
=====
http://fuse.sourceforge.net/
- any FUSE related strange messages in /var/log/messages (since boot time or
FUSE fs mount) ?
- kernel module
$ lsmod |grep -i fuse
$ modinfo fuse
Parameters ?
- verify
# find /etc -iname "*fuse*"
- FUSE fs mount options
Any unusual FUSE (or other) options ? Mounted manually or in /etc/fstab ?
- FUSE fs configuration
"By default FUSE filesystems run multi-threaded. This can be verified by
entering the mountpoint recursively in the fusexmp filesystem.
Multi-threaded operation can be disabled by adding the -s option."
Would that help ?
- FUSE fs with quota (space, files/inodes,...) ? Enabled ?
- application (ioctl ?) vice Linux/UNIX vice FUSE API - conflicts ?
$ man ioctl
...
DESCRIPTION
The ioctl() function manipulates the underlying device parameters of
special files. In particular, many operating characteristics of char�
acter special files (e.g., terminals) may be controlled with ioctl()
requests.
...
NOTES
In order to use this call, one needs an open file descriptor. Often
the open(2) call has unwanted side effects, that can be avoided under
Linux by giving it the O_NONBLOCK flag.
...
$ man tty_ioctl
$ less -i /usr/share/doc/fuse-2.8.5/FAQ
...
Why doesn't FUSE forward ioctl() calls to the filesystem?
---------------------------------------------------------
Because it's not possible: data passed to ioctl() doesn't have a well
defined length and structure like read() and write(). Consider using
getxattr() and setxattr() instead.
- application (ioctl ?) vice Linux/UNIX vice FUSE API - conflicts ?
$ less -i /usr/share/doc/fuse-2.8.5/FAQ
...
What is the reason for IO errors?
---------------------------------
< read this stuff >
...

The app
=======
Because you indicated that you get debug messages up to the moment of lockup,
if you have access to source code you could try to locate the last debug msg
place, or from your gdb session, and try narrow the place or logic where it
happens.

It is quite possible you will need to search their various mailing list
archives or contact devs.

JB


--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines