.
The testcase at https://gist.github.com/lmb/17a528cdadde73fb231a2a1ed84714f7
reproduces this issue as follows:
- Use pthread_sigmask to ignore SIGPIPE
- Create new pipe
- Spawn thread with mdb_env_copyfd2 using MDB_CP_COMPACT
- Close read side of the pipe in main thread
- Join thread and check rc
Full_Name: Lorenz Bauer
Version: git c367c1f69685
OS: OS X
URL: https://gist.github.com/lmb/c48dcdb74b4bc9bf4ecae1d70553d623
Submission from: (NULL) (2a06:98c0:1000:1200:1160:b579:2042:d902)
In case that mdb_txn_begin fails (e.g. due to no more reader slots available),
mdb_env_copyfd1 leaks
Full_Name: Lorenz Bauer
Version:
OS:
URL: https://gist.github.com/lmb/63189f83c5f00dd59c86f3c9bc07694d
Submission from: (NULL) (2606:4700:1000:8200:5530:fc35:2f95:4f31)
As per the discussion in [1] I'm providing a patch to block and handle SIGPIPE
in the copy thread used when perform
--94eb2c07d07472c185053d5903fe
Content-Type: text/plain; charset=UTF-8
I've updated the patch to be much simpler:
* Set pthread_sigmask in copythr and return an error in my->mc_error
* Do not check for pending SIGPIPE: since this is a new thread there can't
be any
The URL stays the same.
--94eb
On 26 September 2016 at 20:48, Hallvard Breien Furuseth
wrote:
> I think we can skip sigwait() too since the thread will exit when done.
> Then any pending signals are presumably dropped. (I suppose some OS
> could give them to another thread, but that goes against delivering
> them to a particul
I think your proposal is going beyond what I was trying to do.
>From the documentation, it sounds like a process using LMDB can not
safely fork, under any circumstances. My idea was to specialise this
to saying that fork() followed immediately by exec() is safe, but that
a plain fork() is still no
On 29 September 2016 at 03:39, Hallvard Breien Furuseth
wrote:
> Yes. Your concern seems to reduce to a doc bug and an
> otherwise- harmless file descriptor leak which it is too late to fix
> completely. So I ended up thinking of resource leaks in general.
Why is it harmless in your opinion?
>
--001a1143758a2a3d2c053ec0c5a5
Content-Type: text/plain; charset=UTF-8
I obviously agree that fixing the problems you mention is worthwhile, it
just so far doesn't really get me what I need: safe fork() + exec().
Well, or mdb_env_open() could take an
> MDB_CLOEXEC flag which says to set FD_CLOEXE
--001a114741aec1bad3053f481b06
Content-Type: text/plain; charset=UTF-8
On 20 October 2016 at 09:35, Hallvard Breien Furuseth <
h.b.furus...@usit.uio.no> wrote:
>
> Hmm. Nevermind, it's probably better to leave that to the user.
> It gets ugly for a library to meddle with the current thread's
> si
Is there anything required from me to make this patch move along?
Full_Name: Lorenz Bauer
Version:
OS: Linux
URL:
Submission from: (NULL) (2a06:98c0:1000:8200:18fd:e772:495e:6163)
This is in some ways a follow up to ITS#8505. In the issue I argued that LMDB
did not deal well with fork/exec. Hallvard committed a fix in
04acac634a7b276332e2. I think the fix sti
Full_Name: Lorenz Bauer
Version: mdb.master
OS: OS X
URL: https://gist.github.com/lmb/a35e7b9566fa79e7bf971ac21bbb9efb
Submission from: (NULL) (2a06:98c0:1000:8200:b860:273:d664:7f97)
It seems like OS X is not standards compliant wrt SIGPIPE, which breaks
mdb_env_copyfd1.
On mdb.master, I can
I should probably mention that this bug will make compacting copies
lock up on OS X, since the copy thread blocks in sigwait forever if
the process set SIG_IGN on SIGPIPE.
Regards,
Lorenz
I've created a test program, available at [1], which will hopefully
help verify this patch.
1:
https://gist.github.com/lmb/a35e7b9566fa79e7bf971ac21bbb9efb#file-0002-add-tests-for-sigpipe-behaviour-patch
Best,
Lorenz
14 matches
Mail list logo