Can't install dhelp

Bug #95083 reported by Emmanuel Pacaud on 2007-03-23
30
Affects Status Importance Assigned to Milestone
dhelp (Ubuntu)
Medium
Unassigned

Bug Description

Binary package hint: dhelp

Installation of dhelp in feisty failed:

pacaud@lappc-p087:~$ sudo apt-get install dhelp
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Reading state information... Fait
dhelp est déjà la plus récente version disponible.
0 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.
1 partiellement installés ou enlevés.
Il est nécessaire de prendre 0o dans les archives.
Après dépaquetage, 0o d'espace disque supplémentaires seront utilisés.
Paramétrage de dhelp (0.5.24) ...
Building HTML tree ...*** stack smashing detected ***: /usr/sbin/dhelp_parse terminated
Aborted (core dumped)
dpkg : erreur de traitement de dhelp (--configure) :
 le sous-processus post-installation script a retourné une erreur de sortie d'état 134
Des erreurs ont été rencontrées pendant l'exécution :
 dhelp
E: Sub-process /usr/bin/dpkg returned an error code (1)

Maftoul Samuel (samuel-maftoul) wrote :

Sames happen here

Changed in dhelp:
status: Unconfirmed → Confirmed
Maftoul Samuel (samuel-maftoul) wrote :

The postinst script runs:
/usr/sbin/dhelp_parse -r

running this command manually does the same:

root@lion:/var/lib/dhelp# /usr/sbin/dhelp_parse -r
*** stack smashing detected ***: /usr/sbin/dhelp_parse terminated
Abandon (core dumped)

I can reproduce this bug on my up to date Herd 5 system (March 23 2007 we are not in beta yet).

Does this package build from source?

Maftoul Samuel (samuel-maftoul) wrote :

In case it helps, gdb backtrace with no debugging symbols, I haven't been able to use debugging symbols I installed (with pitti's apt source)

William Grant (wgrant) on 2007-04-03
Changed in dhelp:
importance: Undecided → Medium
gborzi (gborzi) wrote :

Same problem for me, with a dirty workaround. Trying to debug the code, I added to the dhelp_parse.c a line into the "void dhelp_add_rec (char *dirname)" function to print the current directory, i.e. I added a simple printf("%s\n",zw); between lines 753-754 and recompiled with "-g -O0" flags. Then I moved to /var/lib/dhelp and launched "sudo <path to the modified dhelp_parse>/dhelp_parse -r" and it worked ! I'm not sure, but this looks like a gcc bug rather than a dhelp bug.

I am no longer having this issue on Feisty. I'll mark as Fix Release unless someone says this is still happening.

Changed in dhelp:
status: Confirmed → Incomplete
William Grant (wgrant) wrote :

When marking bugs as Fix Released, it's usually a good idea to mark them as Fix Released.

Changed in dhelp:
status: Incomplete → Fix Released

Sorry William, I mean to say: "I'll mark as Fix Committed when someone else verifies its working for them now."

gborzi (gborzi) wrote :

I still have this problem on my laptop. Tried uninstalling and reinstalling the package, and I got the "stack smashing" error message. I resorted to the dirty workaround.

I can install in 32-bit, are you using 64-bit my any chance?

gborzi (gborzi) wrote :

For me it doesn't work on 32 bit, but works on 64 bit. Maybe it depends on the amount of data to parse, I have less docs installed in the 64 bit system.

Lloyd (lmhpub-ubuntu) wrote :

William Grant, it's still happening. Today, in fact.

I just added a comment on Bug #102434, an alleged duplicate of this bug, where I was upgrading from the previous Ubuntu version. This was a 32-bin system, if it matters. I wouldn't say that it was fixed, unless you didn't put it out on the update site, or wherever it gets it up the upgrade.

So, where do I sit now? How do I find out if I'm all the way upgraded to FF? It seems like it stopped in the middle of the upgrade, and it won't budge past dhelp when it core dumps.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers