TIP: Click on subject to list as thread! ANSI
echo: fidosoft.husky
to: Nick Voronin
from: Gert Koefoed Andersen
date: 2009-08-17 08:12:48
subject: Re: Bugs by hpt

* Reply to message originally in area CarbonArea

Hello Nick!

Sun Aug 16 2009, Nick Voronin wrote to Gert Koefoed Andersen:

 GA>> Program version ___________________Htp/lnx 1.4.0-sta_27-11-08

 NV>Sorry, there is no such version :-P

It is what my log said

 NV>At least do it properly. In any reasonably recent (if not all) version 
 NV>there should be date in this line.

Sorry forgot was thinking it not have to bee in it. date is 27-11-08

 GA>> (the 1st line from `hpt -h` output)

 GA>> Bug description _Hpt craches with rescan of echoes
 GA>> (Screen output: hpt: structrW.c:1042: decode_subfiled: Assertion
 GA>> '(byte *)(subfieldNext+1)dubfield0].buffer' failed)

 NV>JAM? Do update to latest sources. Not necessarily current, latest 
 NV>stable will do too. If bug persists we'll try something.

ok, I try to latest stable by cvs if I can do it for an amd64 pc.
Jes it is all JAM areas Netmail and echo areas.

 GA>> Can bug be reproduced? [x]yes  [ ]no ???

 NV>Can you give developer some exact description so he could reproduce 
 NV>(make it happen) bug on his machine? Is it just random appearing error 
 NV>or is there strong dependency on some factor. (many messages? how many? 
 NV>and how many does not result in error? do rescan ALWAYS produce this 
 NV>error with certain number of messages? Is it any echo with many 
 NV>messages or is it only particular echo?)

Yes, New Links is mostly try to link and rescan all echoes with in netmail
use this command '%rescan *' and it makes hpt to crash and not delete the
lock file so the hpt and other husky not is process before I have seen it
and have delete the lock file and it keeps to precess the rescan and
conitue crash hpt as the netmail still not is marked RCV why the rescan not
was finished. I have tried then self to then do a new netmail for see if it
can rescan with digits as /r=50 30 20 10 5 down to 3 and still the same
happens.
THis mostly happens when a new link try rescan all the echoes and have
linked to all the echoes he can link to and when there is lot of echoes
like fidonet echoes.

 NV>Oh, btw, since it assertion fail may it be that your message base is 
 NV>broken? It may happen... I don't know any linux utilities to check jam 
 NV>message base integrity. Maybe someone else knows.

Could be but some times have I to delete all the echoes files in my
/fido/msgb/ directory.

 GA>> Debugging log
 GA>> (using `Loglevels 0-9A-Za-z`): src/areafix.c:SuscribeAreaCheck()

 NV>huh?? Is it last message before stop? I don't see how it is related to 
 NV>error message :-\ Copy log from start to stop. If it's big and you 
 NV>can't cut repeated irrelevant bloat -- send it whole to 
 NV>elfy.nv{at}gmail.com

 GA>> _____________________________________________________________

 GA>> Hpt is compile by cvs on linux 64bit amd64.

 NV>LOL. Shouldn't it be in OS version? Well, doesn't matter now. There is 
 NV>really not much to say about 64-bit compilation. If it works -- it's by 
 NV>accident ^_^ Though if you are willing to cooperate on this particular 
 NV>occasion then I'll be glad to help. But I need more data.

ok.
I will try to see if I can update by cvs and compile the latest cvs or then
I must try to use the oter way aroung by emerge why it is a Gentoo system.


  Take care,
            Gert

      - Get the best with linux - 

--- Msged/LNX 6.2.0 (Linux/2.6.28-gentoo-r5 (x86_64))
* Origin: * The KofoBBS at http://www.kofobbs.dk * (2:236/150)
SEEN-BY: 10/1 3 11/200 201 331 34/999 120/228 128/2 187 140/1 222/2 226/0
SEEN-BY: 236/150 249/303 250/306 261/20 38 100 1404 1406 1418 266/1413
SEEN-BY: 280/1027 320/119 393/68 396/45 633/104 260 267 285 712/848 800/432
SEEN-BY: 801/161 189 2320/100 105 5030/1256
@PATH: 236/150 261/38 633/260 267

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.