Re: [RFU][1.3.9-2] pv
On 10/12/2012 20:15, Corinna Vinschen wrote: Cygwin supports mmap for a long time. However, I'm puzzled why using POSIX message queues should be more work than implementing the message transport from scratch. This sounds much more error prone than using an existing mechanism. I have never used POSIX message queues, and that would only give me -R in any case, since I would still either need shared memory or a new positioning algorithm for -c. Instead, I would open a lock file and use that to co-ordinate which PV is the first one and where the top Y co-ordinate is. I might not even need mmap() at all. So long as I'm using lock files for the terminal anyway, it seems that I might as well also use them for the rest of -c and -R. So this is why I think it would be easier to use lock files and/or mmap than trying to use message queues.
Re: [RFU][1.3.9-2] pv
Corinna Vinschen wrote: Again, Cygwin supports SYSV IPC. Please inform the original author that the functionality depends on a running cygserver process. If this process is not running, the SYSV IPC functions return ENOSYS. IMHO there's no reason to exit if the msgget function returns ENOSYS. The code could simply note the fact and proceed, and only return an error if the user tried the -R option. SYSV message queue support in Cygwin exists, but it requires to run cygserver. If you want to avoid this dependency, you can use POSIX message queues instead. I think it should be possible to get -R working in Cygwin without cygserver using temporary files to send the message. This isn't a great solution but it's a lot less work, and more portable, than trying to use POSIX message queues. The temporary file would be something like /tmp/pv-EUID-PID.msg, and would be opened with O_NOFOLLOW and O_EXCL to avoid symlinking attacks; does this sound like a reasonable plan? Similarly, temporary files might work for replacing -c shared memory code. Does Cygwin support mmap()? I could mmap() a file of the form /tmp/pv-TERMINAL-shm.dat and use that to pass Y co-ordinate and process count information.
Re: [RFU][1.3.9-2] pv
On Dec 10 15:56, Aaron Schneider wrote: Corinna Vinschen wrote: Again, Cygwin supports SYSV IPC. Please inform the original author that the functionality depends on a running cygserver process. If this process is not running, the SYSV IPC functions return ENOSYS. IMHO there's no reason to exit if the msgget function returns ENOSYS. The code could simply note the fact and proceed, and only return an error if the user tried the -R option. SYSV message queue support in Cygwin exists, but it requires to run cygserver. If you want to avoid this dependency, you can use POSIX message queues instead. I think it should be possible to get -R working in Cygwin without cygserver using temporary files to send the message. This isn't a great solution but it's a lot less work, and more portable, than trying to use POSIX message queues. The temporary file would be something like /tmp/pv-EUID-PID.msg, and would be opened with O_NOFOLLOW and O_EXCL to avoid symlinking attacks; does this sound like a reasonable plan? Similarly, temporary files might work for replacing -c shared memory code. Does Cygwin support mmap()? I could mmap() a file of the form /tmp/pv-TERMINAL-shm.dat and use that to pass Y co-ordinate and process count information. Cygwin supports mmap for a long time. However, I'm puzzled why using POSIX message queues should be more work than implementing the message transport from scratch. This sounds much more error prone than using an existing mechanism. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFU][1.3.9-2] pv
On Dec 7 00:10, Aaron Schneider wrote: pv updated from 1.3.9-1 to 1.3.9-2, first one was crashing at startup. Changelog: - Added --disable-ipc to CYGCONF_ARGS in cygport file: Cygwin does not support the msgget function for IPC. You will need to disable IPC support in PV with configure --disable-ipc before recompiling. This means that -R will be unavailable. Again, Cygwin supports SYSV IPC. Please inform the original author that the functionality depends on a running cygserver process. If this process is not running, the SYSV IPC functions return ENOSYS. IMHO there's no reason to exit if the msgget function returns ENOSYS. The code could simply note the fact and proceed, and only return an error if the user tried the -R option. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFU][1.3.9-2] pv
On 07/12/2012 10:58, Corinna Vinschen wrote:
Again, Cygwin supports SYSV IPC. Please inform the original author that
the functionality depends on a running cygserver process. If this
process is not running, the SYSV IPC functions return ENOSYS.
IMHO there's no reason to exit if the msgget function returns ENOSYS.
The code could simply note the fact and proceed, and only return an
error if the user tried the -R option.
The function has not returned ENOSYS, instead the process has received a
signal, according to gdb's output. This is arguably a bug in Cygwin.
If msgget fails, it should return an error rather than raising a signal.
If it returns an error, pv will handle that.
$ gdb pv
GNU gdb (GDB) 7.5.50.20120815-cvs (cygwin-special)
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as i686-cygwin.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/bin/pv...Reading symbols from
/usr/lib/debug/usr/bin/pv.exe.dbg...done.
done.
(gdb) break main.c:1
Breakpoint 1 at 0x4014b7: file /usr/src/debug/pv-1.4.0-1/src/main/main.c, line
1.
(gdb) s
The program is not being run.
(gdb) run
Starting program: /usr/bin/pv
[New Thread 165608.0x25670]
[New Thread 165608.0x27604]
Breakpoint 1, main (argc=1, argv=0x28ac60) at
/usr/src/debug/pv-1.4.0-1/src/main/main.c:50
50 return 64;
(gdb) s
36 {
(gdb) s
43 setlocale(LC_ALL, );
(gdb) s
44 bindtextdomain(PACKAGE, LOCALEDIR);
(gdb) s
45 textdomain(PACKAGE);
(gdb) s
48 opts = opts_parse(argc, argv);
(gdb) s
opts_parse (argc=1, argv=0x28ac60) at
/usr/src/debug/pv-1.4.0-1/src/main/options.c:51
51 struct option long_options[] = {
(gdb) s
49 {
(gdb) s
51 struct option long_options[] = {
(gdb) s
49 {
(gdb) s
51 struct option long_options[] = {
(gdb) s
80 int option_index = 0;
(gdb) s
86 opts = calloc(1, sizeof(*opts));
(gdb) s
87 if (!opts) {
(gdb) s
86 opts = calloc(1, sizeof(*opts));
(gdb) s
87 if (!opts) {
(gdb) s
95 opts-program_name = argv[0];
(gdb) s
98 opts-argv = calloc(argc + 1, sizeof(char *));
(gdb) s
97 opts-argc = 0;
(gdb) s
98 opts-argv = calloc(argc + 1, sizeof(char *));
(gdb) s
99 if (!opts-argv) {
(gdb) s
98 opts-argv = calloc(argc + 1, sizeof(char *));
(gdb) s
99 if (!opts-argv) {
(gdb) s
111 opts-interval = 1;
(gdb) s
244 opts-pidfile = optarg;
(gdb) s
109 numopts = 0;
(gdb) s
111 opts-interval = 1;
(gdb) s
244 opts-pidfile = optarg;
(gdb) s
241 opts-remote = pv_getnum_i(optarg);
(gdb) s
232 opts-buffer_size = pv_getnum_ll(optarg);
(gdb) s
229 opts-rate_limit = pv_getnum_ll(optarg);
(gdb) s
115 c = getopt_long(argc, argv, /* RATS: ignore */
(gdb) s
121 if (c 0)
(gdb) s
115 c = getopt_long(argc, argv, /* RATS: ignore */
(gdb) s
121 if (c 0)
(gdb) s
265 } while (c != -1);
(gdb) s
270 if (0 == numopts) {
(gdb) s
271 opts-progress = 1;
(gdb) s
272 opts-timer = 1;
(gdb) s
273 opts-eta = 1;
(gdb) s
274 opts-rate = 1;
(gdb) s
275 opts-bytes = 1;
(gdb) s
281 while (optind argc) {
(gdb) s
286 }
(gdb) s
main (argc=1, argv=0x28ac60) at /usr/src/debug/pv-1.4.0-1/src/main/main.c:49
49 if (NULL == opts)
(gdb) s
48 opts = opts_parse(argc, argv);
(gdb) s
49 if (NULL == opts)
(gdb) s
52 if (opts-do_nothing) {
(gdb) s
60 if (opts-remote 0) {
(gdb) s
69 state = pv_state_alloc(opts-program_name);
(gdb) s
pv_state_alloc (program_name=0x8003b070 /usr/bin/pv) at
/usr/src/debug/pv-1.4.0-1/src/pv/state.c:20
20 state = calloc(1, sizeof(*state));
(gdb) s
21 if (0 == state)
(gdb) s
20 state = calloc(1, sizeof(*state));
(gdb) s
21 if (0 == state)
(gdb) s
24 state-program_name = program_name;
(gdb) s
26 state-pv_crs_shmid = -1;
(gdb) s
27 state-pv_crs_pvcount = 1;
(gdb) s
29 state-pv_crs_lock_fd = -1;
(gdb) s
24 state-program_name = program_name;
(gdb) s
31 state-reparse_display = 1;
(gdb) s
32 state-current_file = _(none);
(gdb) s
35 }
(gdb) s
main (argc=1,
Re: [RFU][1.3.9-2] pv
On Dec 7 16:46, Aaron Schneider wrote: On 07/12/2012 10:58, Corinna Vinschen wrote: Again, Cygwin supports SYSV IPC. Please inform the original author that the functionality depends on a running cygserver process. If this process is not running, the SYSV IPC functions return ENOSYS. IMHO there's no reason to exit if the msgget function returns ENOSYS. The code could simply note the fact and proceed, and only return an error if the user tried the -R option. The function has not returned ENOSYS, instead the process has received a signal, according to gdb's output. This is arguably a bug in Cygwin. No, it isn't. Calling a non-existant function raises a SIGSYS signal. That's ok per POSIX (albeit it's an XSI extension). pv could simply call signal (SIGSYS, SIG_IGN) and then just fetch the error code returned from msgget. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
