unofficial mirror of notmuch@notmuchmail.org
 help / color / mirror / code / Atom feed
From: David Bremner <david@tethera.net>
To: notmuch@notmuchmail.org
Subject: [Frederic Bonnard] Bug#803363: [PATCH] notmuch: workaround for FTBFS
Date: Thu, 29 Oct 2015 07:31:14 -0300	[thread overview]
Message-ID: <8737wu6k5p.fsf@zancas.localnet> (raw)

[-- Attachment #1: Type: text/plain, Size: 42 bytes --]


opinions? Shall I apply this in 0.21?




[-- Attachment #2: Type: message/rfc822, Size: 7290 bytes --]

From: Frederic Bonnard <frederic@fr.ibm.com>
To: submit@bugs.debian.org
Subject: Bug#803363: [PATCH] notmuch: workaround for FTBFS
Date: Thu, 29 Oct 2015 10:29:59 +0100
Message-ID: <20151029102959.GC32083@kin.test.toulouse-stg.fr.ibm.com>

Source: notmuch
Source-Version: 0.21~rc3-3
Tags: patch
User: debian-powerpc@lists.debian.org
Usertags: ppc64el 

--

Hi,
on ppc64el, there is a FTBFS on this version since 0.20.2-2 due a test
failing (070).
This is due to the fact that the test is using a breakpoint on the function
notmuch_database_add_message so that it can force a return code and check
the exit code of the binary is the one injected, but for some reason, gdb
fails to trap that function : the breakpoint does not interrupt the program.
In the early days, this was known because of the ABIv2 that makes a function
have a Local Entry Point and a Global Entry Point.
And gdb placed a breakpoint on notmuch_database_add_message, on the address
off the GEP, and in some case you only get through the LEP, and then
the breakpoint is not called.
For reference : https://sourceware.org/ml/gdb-patches/2014-01/msg01013.html
This should be fixed in gdb now, but it seems there's an issue on that.
So the workaround for the moment is to place a 2nd breakpoint on the LEP,
which is at the address of notmuch_database_add_message + 8.
On other architectures, this won't cause trouble as the first one will be
activated and return with the forced exit code will be done.
So notmuch is not broken, but there is something wrong with gdb, and
in the meantime, I need to check with gdb what's going on.
F.

---
Index: sources-notmuch/0.21~rc3-3/test/T070-insert.sh
===================================================================
--- sources-notmuch/0.21~rc3-3/test/T070-insert.sh
+++ sources-notmuch/0.21~rc3-3/test/T070-insert.sh
@@ -192,8 +192,9 @@
 gen_insert_msg
 cat <<EOF > index-file-$code.gdb
 set breakpoint pending on
 break notmuch_database_add_message
+break *notmuch_database_add_message+8
 commands
 return NOTMUCH_STATUS_$code
 continue
 end


             reply	other threads:[~2015-10-29 11:00 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-29 10:31 David Bremner [this message]
2015-10-29 11:12 ` [Frederic Bonnard] Bug#803363: [PATCH] notmuch: workaround for FTBFS David Bremner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://notmuchmail.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8737wu6k5p.fsf@zancas.localnet \
    --to=david@tethera.net \
    --cc=notmuch@notmuchmail.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://yhetil.org/notmuch.git/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).