search for: set_blocking

Hi all, I'm the author of flactag, a utility for tagging whole-album FLAC files with embedded CUE sheets using data from the MusicBrainz servers. I've recently run it through valgrind, and I'm seeing memory leaks like the following: 12 bytes in 1 blocks are definitely lost in loss record 1 of 5 at 0x402377E: operator new(unsigned) (vg_replace_malloc.c:224) by 0x41448A8:

...o problems. Actual error occurs at the second connect() in socketpair_tcp() (line 737) and the errno is EINPROGRESS. close(listener); if (connect_done == 0) { >>> if (connect(fd[1], (struct sockaddr *)&sock, sizeof sock) != 0 && errno != EISCONN) goto failed; } set_blocking(fd[1]); Then it hits "goto failed" and there "listener" is closed as it is not -1 and fails. This overrides the errno to EBADF. I think -1 should be set to "listener" after the close() to avid this problem. The real problem is that "fd[1]" is non-blocking...

On Sun, Jun 12, 2011 at 12:30 AM, <flac-dev-request at xiph.org> wrote: > Send Flac-dev mailing list submissions to > flac-dev at xiph.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.xiph.org/mailman/listinfo/flac-dev > or, via email, send a message with subject or body 'help' to > flac-dev-request at

> I've recently run it through valgrind, and I'm seeing memory leaks like the > following: > > 12 bytes in 1 blocks are definitely lost in loss record 1 of 5 > at 0x402377E: operator new(unsigned) (vg_replace_malloc.c:224) > by 0x41448A8: FLAC::Metadata::local::construct_block(FLAC__StreamMetadata*) > (in /usr/lib/libFLAC++.so.6.2.0) ? by 0x41455D7: >

[This email is either empty or too large to be displayed at this time]

...;); exit_cleanup(RERR_IPC); } if (to_child_pipe[0] != STDIN_FILENO) close(to_child_pipe[0]); if (from_child_pipe[1] != STDOUT_FILENO) close(from_child_pipe[1]); set_blocking(STDIN_FILENO); if (blocking_io > 0) set_blocking(STDOUT_FILENO); execvp(command[0], command); // command is "SSH -l user 192.168.xx.xx rsync --server -vlogxxxxx " rsyserr(FERROR, errno, "Failed to exec %s&quot...

...2 to child stdin : %s\n", + strerror(errno)); + exit_cleanup(RERR_IPC); + } + if (dup2(out, STDOUT_FILENO) < 0) { + rprintf(FERROR, "Failed dup2 to child stdout : %s\n", + strerror(errno)); + exit_cleanup(RERR_IPC); + } + close(pipefds[1]); + umask(orig_umask); + set_blocking(STDIN_FILENO); + if (blocking_io) { + set_blocking(STDOUT_FILENO); + } + execvp(command[0], command); + rprintf(FERROR, "Failed to exec %s : %s\n", + command[0], strerror(errno)); + exit_cleanup(RERR_IPC); + } + + *pipe_to_filter = pipefds[1]; + + return pid; +} + +pid_t run_filt...

...-NORETURN void _exit_cleanup(int code, const char *file, int line); +NORETURN void _exit_cleanup(int code, const char *file, int line) NORETURN2; void cleanup_disable(void); void cleanup_set(char *fnametmp, char *fname, struct file_struct *file, int fd_r, int fd_w); @@ -276,8 +276,8 @@ void set_blocking(int fd); int fd_pair(int fd[2]); void print_child_argv(char **cmd); -NORETURN void out_of_memory(char *str); -NORETURN void overflow_exit(char *str); +NORETURN void out_of_memory(char *str) NORETURN2; +NORETURN void overflow_exit(char *str) NORETURN2; int set_modtime(char *fname, time_t modtime,...

...int force_change; +@@ -45,6 +46,8 @@ * its contents, otherwise just checks for content. Returns DR_SUCCESS or * DR_NOT_EMPTY. Note that fname must point to a MAXPATHLEN buffer! (The * buffer is used for recursion, but returned unchanged.) @@ -786,13 +786,13 @@ @@ -353,7 +354,7 @@ void set_blocking(int fd); int fd_pair(int fd[2]); void print_child_argv(const char *prefix, char **cmd); - int set_modtime(const char *fname, time_t modtime, uint32 mod_nsec, mode_t mode); + int set_modtime(const char *fname, time_t modtime, uint32 mod_nsec, mode_t mode, uint32 fileflags); -int make_path(char...

(Versions: OpenSSH_3.7.1p2, rsync version 2.6.2) I've just encountered a situation where "rsync -v -n" appears to run normally, but reports many fewer file transfers than actually get done when you remove the -n. (This is not one of the usual "-n" corner cases.) It turns out that this only happens when you're doing a remote rsync over ssh AND you redirect stderr into

...ns Leidekker (18): winhttp: Use the thread pool for the connection collector. winhttp: Make sure the COM request object is properly initialized. winhttp: Use the thread pool for COM object requests. winhttp: Store Accept headers like the other headers. webservices: Use set_blocking in more places. webservices: Call WsReadEndElement just once in WsReadEnvelopeEnd. webservices: Return HRESULT from read_cmp. webservices: Get rid of read_rewind. webservices: Return HRESULT from read_utf8_char. webservices: Add support for stream input. bcrypt:...

Hi, this is the next version of quota support for quota tools. I've addressed all the comments of Tao, Joel and others. Sparse feature disabling also correctly updates quota information now and the patch is merged into the tunefs support patch. Honza

Also available here: https://github.com/rwmjones/nbdkit/tree/2020-windows-mingw This is the port to Windows using native Windows APIs (not MSYS or Cygwin). This patch series is at the point where it basically now works. I can run the server with the memory plugin, and access it remotely using guestfish, creating filesystems and so on without any apparent problems. Nevertheless there are many

Also available here: https://github.com/rwmjones/nbdkit/tree/2020-windows-mingw-nolib After a lot of work I have made the port to Windows work without using a separate library. Instead, on Windows only, we build an "import library" (library of stubs) which resolves references to nbdkit_* functions in the main program and fixes up the plugin, basically the first technique outlined in

Hi, I'm sending a series of patches implementing quota support into ocfs2-tools. It's the same as the original huge patch I've sent but now it's split as Joel asked. I've also realized that when disabling SPARSE feature, we should update quota information. That piece of code is missing, I'll implement it soon. Comments welcome. Honza

Hi, below comes a new version of the series of patches implementing quota support for ocfs2-tools. I've fixed the calls of ocfs2_malloc_blocks() which were given number of bytes instead of number of blocks. Besides that the series should be the same. Honza