Ubuntu
praat package

hangs on startup

Bug #3442 reported by Steve White
10
Affects Status Importance Assigned to Milestone
praat (Ubuntu)
Fix Released
High
MOTU

Bug Description

Why, the program hangs on startup.

Might be looking in the wrong place for libraries.

Below are the last few lines of the output of
strace praat

...
open("/usr/local/lib/libXau.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/opt/intel/compiler90/lib/libXau.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/usr/lib/libXau.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20\f\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=7648, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7b59000
old_mmap(NULL, 10640, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7b56000
old_mmap(0xb7b58000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0xb7b58000
close(3) = 0
open("/usr/local/lib/libXdmcp.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/opt/intel/compiler90/lib/libXdmcp.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/usr/lib/libXdmcp.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\17"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=9636, ...}) = 0
old_mmap(NULL, 12664, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7b52000
old_mmap(0xb7b55000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0xb7b55000
close(3) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7b51000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7b518e0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
munmap(0xb7f87000, 109656) = 0
set_tid_address(0xb7b51928) = 7856
rt_sigaction(SIGRTMIN, {0xb7c8f3d0, [], SA_SIGINFO}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0xb7c8f450, [], SA_RESTART|SA_SIGINFO}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
_sysctl({{CTL_KERN, KERN_VERSION, 0, 20d91, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, 2, 0xbf8b8e2c, 31, (nil), 0}) = 0

Andrew Mitchell (ajmitch)
Changed in praat:
assignee: nobody → motu
Revision history for this message
Yann Rouillard (yann-pleiades) wrote :

I don't reproduce this bug on dapper drake.
Can you test again with last developpment version of Ubuntu (Dapper Drake) ?

Changed in praat:
status: Unconfirmed → Needs Info
Revision history for this message
Francois-Denis Gonthier (fdgonthier) wrote :

I just tested this package on Dapper. It might not be related to what the original poster has experienced, but the package crashes at start on Dapper AMD64, but not in my i386 chroot.

Backtrace:

#0 0x00002aaaab0b6b9f in _XtCountVaList () from /usr/lib/libXt.so.6
#1 0x00002aaaab0b57ff in XtVaSetValues () from /usr/lib/libXt.so.6
#2 0x0000000000614e0c in ?? ()
#3 0x0000000000621480 in ?? ()
#4 0x0000000000611412 in ?? ()
#5 0x00000000004063ef in ?? ()
#6 0x00002aaaab9c249b in __libc_start_main () from /lib/libc.so.6
#7 0x000000000040619a in ?? ()
#8 0x00007fffff859f38 in ?? ()
#9 0x000000000000001c in ?? ()
#10 0x0000000000000001 in ?? ()
#11 0x00007fffff85a8c5 in ?? ()
#12 0x0000000000000000 in ?? ()

Revision history for this message
Francois-Denis Gonthier (fdgonthier) wrote :

The newest source from upstream build fine on my PC but it still crashes at start. The program might not be AMD64 compatible. I will contact upstream and ask him about 64 bit platforms.

This time thought, I've got a more useful backtrace :)

#0 0x00002aaaab0b6b9f in _XtCountVaList () from /usr/lib/libXt.so.6
#1 0x00002aaaab0b57ff in XtVaSetValues () from /usr/lib/libXt.so.6
#2 0x0000000000616c5c in praat_addFixedButtonCommand ()
#3 0x00000000006232e0 in praat_addFixedButtons ()
#4 0x0000000000613252 in praat_init ()
#5 0x000000000040639f in main ()

Changed in praat:
status: Needs Info → Confirmed
Revision history for this message
Francois-Denis Gonthier (fdgonthier) wrote :

Upstream has been very helpful. I spent some time on that today and finally discovered that the way XtVaSetValues was called at one point made the program read past the list of arguments passed in the va_list. On a 64 platform, NULL != 0 apparently.

Anyway, this is only my second attempt at a debdiff, and this one is not trivial. The patch does fix the bug (at least praat starts now), but the way it was generated might be incorrect. I have used the Ubuntu package as the base since it's the same as in Debian.

[Patch will follow]

Revision history for this message
Francois-Denis Gonthier (fdgonthier) wrote : praat AMD64 patch.

Here it is.

Revision history for this message
Ming Hua (minghua) wrote :

Nice work. The patch looks quite straight forward, I'll look at it in more detail soon.

Revision history for this message
Francois-Denis Gonthier (fdgonthier) wrote :

Please wait before uploading this patch. I'm still discussing with Paul Boersma, one of the upstream authors. If he release a bugfix version of praat that is more 64 bit friendly, I'll ask Rafael Laboissiere to update so we can do fakesync. My patch makes the software start on AMD64, which is the minimum I wanted, but I don't do phonetics on PC so I can't really test this software toughroughly for other portability problems. I'd be much more comfortable with fixes coming from the upstream authors.

Revision history for this message
Francois-Denis Gonthier (fdgonthier) wrote :

As I thought, the patch do not cover all potential cases. Paul Boersma has updated the package upstream. I have asked Raphael Laboissière if he can manage to update soon, and then we'll be able to fakesync.

Revision history for this message
Francois-Denis Gonthier (fdgonthier) wrote :

Praat has been updated by Paul Boersma, and Raphael quickly followed.

A fakesync of that package should be done with the Debian version 4.4.14-1 which is now in unstable.

Revision history for this message
Francois-Denis Gonthier (fdgonthier) wrote :

praat fakesync with Debian's 4.4.14-1

http://revu.tauware.de/details.py?upid=2226

Revision history for this message
Barry deFreese (bddebian) wrote :

Unfortunately it is likely that this isn't going to make in in Dapper, it will have to go into Dapper+1

Revision history for this message
Francois-Denis Gonthier (fdgonthier) wrote :

Then you should exclude the AMD64 architecture for this package since it's totally unusable in it's current state.

BTW, the changes from 4.4.12 to 4.4.14 are bugfixes: the minimum changes required to avoid potential crashes on AMD64. You can see it from the debdiff.

Revision history for this message
Sebastian Dröge (slomo) wrote :

Please file a UVF exception for it so we can get this into dapper: https://lists.ubuntu.com/archives/ubuntu-motu/2006-February/000545.html

IMHO it should be fine to update as it's a) not working at all on amd64 currently and b) the changes are only bugfixes from what you said

Revision history for this message
LaserJock (laserjock) wrote :

a praat UVF exception was approved and 4.4.19-1ubuntu1 was uploaded to Dapper. This should fix the problem. If it doesn't please reopen the bug.

Changed in praat:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.