3

I am working on a French chatbot using python. For a first text-to-speech attempt, I am using espeak with mbrola. I call it with subprocess :

from subprocess import run, DEVNULL

def speak(text):
    command = ["espeak", "-vmb-fr1", text]
    run(command, stderr=DEVNULL, stdout=DEVNULL)

speak("Bonjour.")

As you see, I'm sending stderr and stdout to /dev/null

When I run the program, It seems to work, espeak is speaking, but I get this :

*** Error in `mbrola': free(): invalid pointer: 0x08e3af18 ***
*** Error in `mbrola': free(): invalid pointer: 0x0988af88 ***

I think it is a C error in mbrola. I think I can't fix it. But it works, so I just want to mute the error. How can I do ? Is there a way ?

Edit, in response to abarnert :

When I redirect stdout and stderr by the shell (python myscript.py 2>&1 >/dev/null), the message still show up.

  • distro : Debian 9.3
  • glibc version : 2.24
cdrom
  • 591
  • 2
  • 16
  • I believe these messages are being emitted by your system malloc library, not by the actual `espeak` or `mbrola` code, because it’s detected a dangerous bug in `mbrola`. And maybe it’s emitting the message to your console, rather than to anything the parent can capture? Try running your script with its own stdout and stderr redirected by the shell and see if the messages still show up. – abarnert Mar 07 '18 at 10:55
  • Thank you for your comment. Please can you tell what do you mean by "running your script with its own stdout and stderr redirected by the shell" ? Sorry if it is a stupid question. – cdrom Apr 27 '18 at 21:09
  • `python myscript.py 2>&1 >/dev/null` – abarnert Apr 27 '18 at 21:44
  • It still show up... – cdrom Apr 27 '18 at 22:04
  • 2
    First, does `set |grep MALLOC_CHECK_` show you anything? Next, what happens if you `export MALLOC_CHECK_=0` and try your code again? (Notice the funky extra underscore on the end of the name. It's important.) Meanwhile, have you checked for newer versions of espeak/mbrola, or filed a bug with them? – abarnert Apr 28 '18 at 00:30
  • Also, which OS/distro (including exact version) are you using? And if you know which glibc version, that too. – abarnert Apr 28 '18 at 00:33
  • @abarnert thank you very much for your help. `export MALLOC_CHECK_=0` solve my problem. I am accepting [the Davis' answer](https://stackoverflow.com/a/50072485/8752259) that also solve it. – cdrom Apr 28 '18 at 12:06

2 Answers2

2

Run it with setsid (just add that string in front of the command and arguments). That will stop it from opening /dev/tty to report the malloc errors. It will also prevent terminal signals, including SIGHUP when the terminal is closed, from affecting the process, which may be a good or a bad thing.

Alternatively, set the environment variable LIBC_FATAL_STDERR_ to some nonempty string, with whose name I was able to find several similar questions.

Davis Herring
  • 36,443
  • 4
  • 48
  • 76
  • Thank you ! I think that running espeak with setsid is the simplest solution. I will use it. – cdrom Apr 28 '18 at 12:09
1

The root problem is that mbrola/espeak has a serious bug with memory allocation. If you haven't checked for a new version, and reported the bug to them, that's the first thing you should do.

These warnings are emitted by glibc's malloc checker, which is described in the mallopt docs. If heap checking is enabled, every detected error with malloc (and free and related functions) will be printed out to stderr, but if it's disabled, nothing will be done. (Other possibilities are available as well, but that's not relevant here.)

According to the documentation, unless the program explicitly calls mallopt, either setting the environment variable MALLOC_CHECK_ to 0 or not setting it at all should mean no malloc debug output. However, most of the major distros (starting with Debian) have long shipped a glibc that's configured to default to 1 (meaning print the error message) instead of 0. You can still override this by explicitly setting MALLOC_CHECK_=0.

Also, the documentation implies that malloc errors go to stderr unless malloc_printerr is replaced. But again, many distros do replace it with an intentionally-harder-to-ignore function that logs to the current process's tty if pretend and stderr if not. This is why it shows up even if you pipe espeak's stderr to /dev/null, and your own program's as well.

So, to hide these errors, you can:

  • Set the environment variable MALLOC_CHECK_ to 0 in espeak, which will disable the checks.
  • Prevent espeak from opening a tty, which means the checks will still happen, but the output will have nowhere to go.

Using setsid, a tool that calls setsid at the start of the new process, is one way to do the latter. Whether that's a good idea or not depends on whether you want the process to lead its own process group. You really should read up on what that means and decide what you want, not choose between the options because typing setsid is shorter than typing MALLOC_CHECK_=0.

And again, you really should check for a new version first, and report this bug upstream if they haven't fixed it yet.

abarnert
  • 354,177
  • 51
  • 601
  • 671