lurker-users — Lurker user support

Re: [Lurker-users] SIGSEGV in service.c (CVS 20030409)

[Wesley W. T. <we...@te...>]

On Sun, Apr 13, 2003 at 09:16:21AM +0800, Federico Sevilla III wrote:
> On Sat, Apr 12, 2003 at 04:36:41PM +0200, Wesley W. Terpstra wrote:
> > Since that will take significant time, I will continue to maintain
> > 0.1* for a while yet. :-)
> 
> Awesome, thanks. I'm curious, though, since you fix changes in CVS, will
> you do drastic work in CVS as well?

Only in a branch. I have been fiddling with code to do what I think
necessary to fix lurker for some time. When I start integrating with the
lurker cvs, it will be as a branch; not as cvs/HEAD.

The fourth attempt at lurker's new database can be seen at:
	http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/lurker/project/
the third attempt at:
	http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/lurker/libtsl/
the second attempt:
	your version of lurker
the first attempt:
	0.1a
the zeroth attempt:
	written at a company where my non-compete clause has run out.
	... also where some friends and I developed lurker's interesting
	threading arrangement. I am amazed no one else has copied it yet.

The version which I am almost done (fifth attempt), is nice and simple, and
will be used in lurker 0.5 -> 1.0 is only available on my hard drive. :-)
... it uses a really spiffy data structure that I custom designed for
lurker. I probably should keep my mouth shut until I release it, but... the
words 'zero' and 'seek' come to mind when describing message imports. ;-)

> What are people like me supposed to track if we need the corner cases
> fixed because we get hit by them, and yet use the archives for "real
> life"? 

cvs/HEAD, or releases.

> If CVS is decently stable (eg: I'm willing to pay the price of the
> current instability if it means helping you get to 1.0 faster and better)
> I'll be willing to use it. 

I intend to keep the transition to whatever lurker 1.0 is as ... compileable
and runnable. :-) However, this transition will be in a branch as noted
above. Once I start merging the new database with lurker -- this will mark
the begin of transition to 1.0. People testing this would be greatly
appriciated; however, DON'T run it on a public server. :-)

> If you intend to have it completely broken until you get to 1.0, maybe
> small mini-releases can be made with the bugfixes only?

I will probably do a 0.1g release in a week or three.

> Ok then. I'll be running Lurker under gdb until we hit 1.0 so I can keep
> sending you backtraces when things break. I'm sure you'll prefer
> backtrace-equipped bug reports than me wailing that lurker keeps dying.

Those backtraces are invaluable.

-- 
Wesley W. Terpstra <we...@te...>

Re: [Lurker-users] Lurker 1.0 Survey

[Kevin B. <co...@co...>]

Federico Sevilla III wrote:
> 
> 
> On Thu, Apr 10, 2003 at 11:25:15PM +0200, Wesley W. Terpstra wrote:
> > Ok, I am going to finally start work on lurker 1.0.
> 
> BTW, about wishlists, I'm curious: how painful will it be to have
> virtual host support in Lurker? I know it sounds weird, and probably
> corner case, but I'm thinking of having internal and external archives
> on the same server. Internal archives being password-protected by Apache
> and accessible only to people within our organization for our internal
> lists, and external archives being completely public.
> 
> I realize that this will probably require separate databases for each
> virtual host and a lot of mumbo-jumbo with the way things work so that
> Lurker knows for which virtual host certain messages are... but I just
> thought I'd ask anyway. Even if you're not planning to take this on,
> please let me know what sort of hell-raising work it'll need so I'll
> know if I should even think about thinking about doing this for my
> undergraduate thesis in June. ;)


Wow, exactly what I want to setup.

I've been think of just running two copies of lurker (or one open and as
many password protected versions as needed.)  Then you can virtual host
each one with password protection or not as needed.

-- 
Kevin

Re: [Lurker-users] Lurker 1.0 Survey

[Federico S. I. <ji...@fr...>]

On Thu, Apr 10, 2003 at 11:25:15PM +0200, Wesley W. Terpstra wrote:
> Ok, I am going to finally start work on lurker 1.0.

BTW, about wishlists, I'm curious: how painful will it be to have
virtual host support in Lurker? I know it sounds weird, and probably
corner case, but I'm thinking of having internal and external archives
on the same server. Internal archives being password-protected by Apache
and accessible only to people within our organization for our internal
lists, and external archives being completely public.

I realize that this will probably require separate databases for each
virtual host and a lot of mumbo-jumbo with the way things work so that
Lurker knows for which virtual host certain messages are... but I just
thought I'd ask anyway. Even if you're not planning to take this on,
please let me know what sort of hell-raising work it'll need so I'll
know if I should even think about thinking about doing this for my
undergraduate thesis in June. ;)

 --> Jijo

-- 
Federico Sevilla III  : http://jijo.free.net.ph      : When we speak of free
Network Administrator : The Leather Collection, Inc. : software we refer to
GnuPG Key ID          : 0x93B746BE                   : freedom, not price.

Re: [Lurker-users] SIGSEGV in service.c (CVS 20030409)

[Federico S. I. <ji...@fr...>]

On Sat, Apr 12, 2003 at 04:36:41PM +0200, Wesley W. Terpstra wrote:
> Since that will take significant time, I will continue to maintain
> 0.1* for a while yet. :-)

Awesome, thanks. I'm curious, though, since you fix changes in CVS, will
you do drastic work in CVS as well? What are people like me supposed to
track if we need the corner cases fixed because we get hit by them, and
yet use the archives for "real life"? If CVS is decently stable (eg: I'm
willing to pay the price of the current instability if it means helping
you get to 1.0 faster and better) I'll be willing to use it. If you
intend to have it completely broken until you get to 1.0, maybe small
mini-releases can be made with the bugfixes only?

> Fixed in CVS. :-)

Thanks. You're really great at this.

> This is that message with the corrupt body again. First time the crash
> was from import, this was from someone viewing it.

Sigh... must be a pain dealing with the variety of messages out there,
and in C at that!

> I hope to keep as much of the current code as possible during
> transition, so it is important to keep nailing down corner-cases like
> this.

Ok then. I'll be running Lurker under gdb until we hit 1.0 so I can keep
sending you backtraces when things break. I'm sure you'll prefer
backtrace-equipped bug reports than me wailing that lurker keeps dying.
;)

Thank you again for your great work, Wesley. Even when 0.1f was broken
for quite awhile I couldn't get myself to try any other archiver out.
None of them had what I've grown to love in Lurker (the searching and
especially the mini-threaded paths). Cheers!

 --> Jijo

-- 
Federico Sevilla III  : http://jijo.free.net.ph      : When we speak of free
Network Administrator : The Leather Collection, Inc. : software we refer to
GnuPG Key ID          : 0x93B746BE                   : freedom, not price.

Re: [Lurker-users] Lurker 1.0 Survey

[Wesley W. T. <we...@te...>]

On Sat, Apr 12, 2003 at 10:00:20AM -0600, Jamin W. Collins wrote:
> However, are you talking about the date sent or the date received?
> Remember some people mis-set their clocks and send messages that appear
> to be from the future or past.

Lurker has a fairly complicated strategy which I like, seems to get things
mostly right, and I intend to keep through all lurker versions.

What it does is it compares the server mbox timestamp (arrival time on the
mailing list server) and the client timestamp. If they are within some
threshold (12 hours I think?) it believes the user timestamp. Otherwise, it
believes the server timestamp.

-- 
Wesley W. Terpstra <we...@te...>

Re: [Lurker-users] buildling cvs

[Wesley W. T. <we...@te...>]

On Sat, Apr 12, 2003 at 05:01:08PM -0400, Kevin Brosius wrote:
> For completeness, the owner of lurkerd and apache need to be able to
> write files in those directories, correct?

The user who invokes lurkerd and lurker.cgi must have access, yes.
Or else the executables must be setuid to such a user.

> On SuSE, Apache runs as uid:wwwrun,gid:nogroup.  Running lurkerd under
> it's own account was a big part of my problem.  The lurker.cgi ran with
> Apache authority, creating files under wwwrun/nogroup.  But lurkerd was
> running as lurker/users.  One of the problems I saw was failure of
> lurkerd to delete cache files, because they are created by lurker.cgi.

What I suggest is to have lurkerd run as lurker/users.
Make lurker.cgi owned by lurker/users.
Then: chmod u+s lurker.cgi
This will make the cgi run with the permissions of the lurker user without
needing to be invoked by the user... and apache can still run as root.

> Anyway, the quick workaround was to run Apache as the lurker user.  It's
> up and running now.  Thanks for the help!

Eek! Don't do that! :-)
Either make the directories world writeable, or make the lurker.cgi setuid.

> I'll be doing some testing, and wondered if the lurker-users list is
> available as an mbox file for download anywhere?  If so, I can put up a
> copy of it in lurker for people to play with.

If anyone has an mbox, it sadly isn't me.

-- 
Wesley W. Terpstra <we...@te...>

Re: [Lurker-users] buildling cvs

[Kevin B. <co...@co...>]

"Wesley W. Terpstra" wrote:
> 
> 
> On Sat, Apr 12, 2003 at 08:46:51AM -0400, Kevin Brosius wrote:
> > I should be able to run lurkerd as a regular user, right?  I had to give
> > it permissions for the web directories, (everything is in group 'www'),
> > and it runs okay, however when I try to use the web browser I see:
> >
> > ----
> > lurker - error rendering page:
> >
> > Unable to create cache file (index.html): Permission denied
> 
> The lurker.cgi must have permission to write files in the splash, message,
> etc directories. Set the cgi as

That was the problem, thank you.

For completeness, the owner of lurkerd and apache need to be able to
write files in those directories, correct?

On SuSE, Apache runs as uid:wwwrun,gid:nogroup.  Running lurkerd under
it's own account was a big part of my problem.  The lurker.cgi ran with
Apache authority, creating files under wwwrun/nogroup.  But lurkerd was
running as lurker/users.  One of the problems I saw was failure of
lurkerd to delete cache files, because they are created by lurker.cgi.

Anyway, the quick workaround was to run Apache as the lurker user.  It's
up and running now.  Thanks for the help!

I'll be doing some testing, and wondered if the lurker-users list is
available as an mbox file for download anywhere?  If so, I can put up a
copy of it in lurker for people to play with.

-- 
Kevin

Re: [Lurker-users] Lurker 1.0 Survey

[Jamin W. C. <jco...@as...>]

On Thu, Apr 10, 2003 at 11:25:15PM +0200, Wesley W. Terpstra wrote:
> Ok, I am going to finally start work on lurker 1.0.
> 
> There will be sweeping changes in this lurker version, but I need to know
> some things about the current user-base first. I am conducting this survey
> verbally and non-anonymously so that I can get more than a simple x users
> for this, y for that. If your answers are open for public debate, reply to
> the list. Otherwise, reply directly to me.
> 
> After I collect this information, I will post a lurker 1.0 requirements list
> and design for further final feedback. After this is finalized, I will
> proceed to implement lurker 0.5, 0.6, ... 0.12 until it's solid -> 1.0.
> 
> If you would like lurker to be useful to you, please let me know:
> 
> 1.  Does your platform have g++ 3.2?

Yes, but it is not default.  Debian still uses 2.95 as the default
compiler.

> 2.  Is 'jam' available for your platform?
>     <http://www.perforce.com/jam/jam.html>

Yes.

> 2a. How much pain does setting it up cause you?

apt-get install
 
> 3. Rank the dependent libraries in order of *DEcreasing* pain:
>    libst, libc-client, libxslt1, libiconv

All avaliable libraries in Debian, so they are all equal in terms of
difficulty.

> 3a. Would you rather lurker.tgz include needed libraries?

Not unless there was some need for a specific version of the libraries.

> 4. Rank these lurker features in *DEcreasing* importance:
>    capacity, threading, caching, search, mime-support, multi-lingual, xslt
>    ... indicate the point where you stop caring.

search, threading, mime-support, capacity (this is the end)

> 5. Would you prefer lurker to run as a normal CGI or do you prefer it's
>    create-page-on-demand 404 error handler approach?

Prefer the create on demand.

> 6. Small database size or fast database?

Fast

> 7. Back-issue import w/o reimport or date-sorted search?

Not entirely sure what you're referring to here.

> 8.  Pretty or small html?

small html

> 8a. How big is too big for the output html?

15% more than necessary to do the job.

> 8b. Is lynx compatability (like now) important?

Should be kept if possible.
 
> 9. How much RAM is too much for lurker to use?

32-64 (not entirely sure what it uses now)

> 10.  Is cleaning up cached .html important or should I keep all valid html?

Should set a max cache size and keep anything valid that stays under
defined size.

> 10a. If clean up: cronjob or daemon? (supposing no normal lurker daemon)

Clean on an oldest out basis when the cache limit is reached.

> 11. Have you ever used lurker's xslt to customize the UI?

No.

> 12. Do you believe the majority of your users have an xslt-capable browser?

Not entirely sure.

> 13. What url-scheme for message viewing do you prefer? (bookmarks/google):
> 	message/message-id.xml	<-- current

Current's fine with me.

> 14. What should be improved most in lurker? (other than stability)

DB fault tolerance.  Possibly even with the option to automatically have
it start from scratch if it can't recover.

-- 
Jamin W. Collins

Re: [Lurker-users] Lurker 1.0 Survey

[Jamin W. C. <jco...@as...>]

On Fri, Apr 11, 2003 at 05:23:37AM -0700, Wesley W. Terpstra wrote:
> On Thu, Apr 10, 2003 at 11:15:13PM -0600, Jamin W. Collins wrote:
> > On Thu, Apr 10, 2003 at 11:25:15PM +0200, Wesley W. Terpstra wrote:
> > > 7. Back-issue import w/o reimport or date-sorted search?
> > 
> > Not entirely sure what you're referring to here.
> 
> Right now, when you want to import messages that are older than the most
> recently imported message, you have to dump the database and start over.
> 
> This is because messages are assigned IDs in chronological order, and I
> return the results in sorted order based on these IDs. This is why you
> always see most recent results first in a search.
> 
> If I have to choose between one or the other, which is more important:
> 	ability to import messages from the past w/o reimport
> 	searches returning recent messages first

Gotcha.  In that case, I would have to say date ordered searches.
However, are you talking about the date sent or the date received?
Remember some people mis-set their clocks and send messages that appear
to be from the future or past.

> > > 9. How much RAM is too much for lurker to use?
> > 
> > 32-64 (not entirely sure what it uses now)
> 
> This is Mb? (right now it uses nearly exactly 8Mb - always)

Yep.  With RAM prices the way they are, I would sacrifice some for
speed.  Might be nice to be able to set an upper-limit in a config file.
 
> The main things I intend to improve right now (subject to being out-voted):
> 	a much faster (!!!), 32-bit ok, and transactional db
> 	using a faster/less-hassles mime parser (mime++)

Sounds good to me.

-- 
Jamin W. Collins

Re: [Lurker-users] SIGSEGV in service.c (CVS 20030409)

[Wesley W. T. <we...@te...>]

On Sat, Apr 12, 2003 at 06:46:07PM +0800, Federico Sevilla III wrote:
> I don't know if this will still be useful considering Wesley's plan to
> redo the codebase

Since that will take significant time, I will continue to maintain 0.1* for
a while yet. :-)

> but here goes anyway:
> 
>     (gdb) run -n
>     Starting program: /usr/sbin/lurkerd -n
>     lurkerd[21243]: Unknown coding: X-UNKNOWN
>     lurkerd[21243]: Unknown coding: x-user-defined
> 
>     Program received signal SIGSEGV, Segmentation fault.
>     0x08056ba3 in my_service_traverse (h=0x91fb19c0, in=0x91fb18f0, body=0x80b9670, count=3, draw=1) at service.c:832
>     832     service.c: Permission denied.
>             in service.c
>     (gdb) bt
>     #0  0x08056ba3 in my_service_traverse (h=0x91fb19c0, in=0x91fb18f0, body=0x80b9670, count=3, draw=1) at service.c:832
>     #1  0x08056b78 in my_service_traverse (h=0x91fb19c0, in=0x91fb18f0, body=0x80b8398, count=2, draw=1) at service.c:821
>     #2  0x08059319 in my_service_message (h=0x91fb19c0, request=0x91fb1a08 "199...@zo...", 
>         ext=0x91fb1a2e "html") at service.c:1848
>     #3  0x0805b15f in lu_service_connection (fd=0x80b9b90) at service.c:2665
>     #4  0x0805caa2 in my_main_handle_client (arg=0x80b9b90) at main.c:137
>     #5  0x40019b02 in st_thread_create () from /usr/lib/libst.so.1
>     #6  0x000f4240 in ?? ()
>     (gdb) continue
>     Continuing.
>     lurkerd[21243]: Program Fault (signal 11) - attempting to salvage db
>     lurkerd[21243]: syncing databases to disk ...

Fixed in CVS. :-)

This is that message with the corrupt body again. First time the crash was
from import, this was from someone viewing it.

I hope to keep as much of the current code as possible during transition, so
it is important to keep nailing down corner-cases like this.

-- 
Wesley W. Terpstra <we...@te...>

Re: [Lurker-users] buildling cvs

[Wesley W. T. <we...@te...>]

On Sat, Apr 12, 2003 at 08:46:51AM -0400, Kevin Brosius wrote:
> I should be able to run lurkerd as a regular user, right?  I had to give
> it permissions for the web directories, (everything is in group 'www'),
> and it runs okay, however when I try to use the web browser I see:
> 
> ----
> lurker - error rendering page:
> 
> Unable to create cache file (index.html): Permission denied

The lurker.cgi must have permission to write files in the splash, message,
etc directories. Set the cgi as 

> Your web browser does not appear to support XSL
Well, really mozilla DOES support xsl, but it is so slow as to be
practically useless.

-- 
Wesley W. Terpstra <we...@te...>

Re: [Lurker-users] buildling cvs

[Kevin B. <co...@co...>]

"Wesley W. Terpstra" wrote:
> 
> 
> On Thu, Apr 10, 2003 at 10:42:55PM -0400, Kevin Brosius wrote:
> > I looked for libc-client, but I don't see it specifically at
> > ftp://ftp.cac.washington.edu/imap/ .  Has it been renamed or moved?
> 
> To be honest; I am not really sure.
> c-client is ancient and has been integrated in different ways to many
> different platforms. I believe imap should be ok.
> 

Seems to work fine...

> > I've completed a compile now, but the link is failing like:
> >
> > gcc  -g -O2 -Wall   -o lurkerd  config.o decode.o md5.o indexer.o
> > summary.o mbox.o search.o service.o expiry.o main.o url.o mailto.o
> > quote.o art.o ../common/libcommon.a ../libkap/libkap.a -L/usr/local/lib
> > -lst   -lm
> 
> Seems to me you are missing a -lc-client on there.
> The undefined references are all about c-client also.
> 
> > But that looks like a problem with my configure changes to get
> > libc-client to be recognized (no -lc-client on the link line:( ).  I'll
> > spend some more time getting this working.  Suggestions welcome :)
> 
> Try:
> LIBS="-lc-client" ./configure ....
> 

Yes, that was it.  On SuSE I also needed "-lssl -lpam", similar to the
previous post about RH.  (But none of the kerberos parts.)

> > Are you interested in autoconf patches if this can be made to work more
> > cleanly on SuSE?
> 
> Yes.
> 
> ---
> Wes

I should be able to run lurkerd as a regular user, right?  I had to give
it permissions for the web directories, (everything is in group 'www'),
and it runs okay, however when I try to use the web browser I see:

----
lurker - error rendering page:

Unable to create cache file (index.html): Permission denied
----

This is in html mode, as with Mozilla I'm seeing the initial connect
message about missing XSL support.

-----
Your web browser does not appear to support XSL
-----

Thank you,
-- 
Kevin

[Lurker-users] SIGSEGV in service.c (CVS 20030409)

[Federico S. I. <ji...@fr...>]

I don't know if this will still be useful considering Wesley's plan to
redo the codebase, but here goes anyway:

    (gdb) run -n
    Starting program: /usr/sbin/lurkerd -n
    lurkerd[21243]: Unknown coding: X-UNKNOWN
    lurkerd[21243]: Unknown coding: x-user-defined

    Program received signal SIGSEGV, Segmentation fault.
    0x08056ba3 in my_service_traverse (h=0x91fb19c0, in=0x91fb18f0, body=0x80b9670, count=3, draw=1) at service.c:832
    832     service.c: Permission denied.
            in service.c
    (gdb) bt
    #0  0x08056ba3 in my_service_traverse (h=0x91fb19c0, in=0x91fb18f0, body=0x80b9670, count=3, draw=1) at service.c:832
    #1  0x08056b78 in my_service_traverse (h=0x91fb19c0, in=0x91fb18f0, body=0x80b8398, count=2, draw=1) at service.c:821
    #2  0x08059319 in my_service_message (h=0x91fb19c0, request=0x91fb1a08 "199...@zo...", 
        ext=0x91fb1a2e "html") at service.c:1848
    #3  0x0805b15f in lu_service_connection (fd=0x80b9b90) at service.c:2665
    #4  0x0805caa2 in my_main_handle_client (arg=0x80b9b90) at main.c:137
    #5  0x40019b02 in st_thread_create () from /usr/lib/libst.so.1
    #6  0x000f4240 in ?? ()
    (gdb) continue
    Continuing.
    lurkerd[21243]: Program Fault (signal 11) - attempting to salvage db
    lurkerd[21243]: syncing databases to disk ...

By the time this was hit the database had already been rebuilt. The
message (#2) doesn't look like it's new, though... I hope this helps.

 --> Jijo

-- 
Federico Sevilla III  : http://jijo.free.net.ph      : When we speak of free
Network Administrator : The Leather Collection, Inc. : software we refer to
GnuPG Key ID          : 0x93B746BE                   : freedom, not price.

Re: [Lurker-users] SIGBUS in mbox.c (CVS 20030409)

[Federico S. I. <ji...@fr...>]

On Fri, Apr 11, 2003 at 05:23:48AM -0700, Wesley W. Terpstra wrote:
> This SIGBUS occured while you were opening a message in the browser,
> correct? So, it was mid-import and you viewed a message. This should
> be ok...

Your hunch is probably correct, but you see this is a public site
already. I do everything with lurker being monitored by GDB nowadays so
I can send you backtraces when things bonk.

> Judging by the code in that region, it has somehow tried to access
> memory past the end of the mmap'd mbox. This is odd since I keep a
> pointer to the end of the mmap/eof.
> 
> If possible, I would love to know the value of variables: 
> 	s, e in my_mbox_find_special
> 	start, amt, buf, e, msg->map.size, msg->map.off in lu_mbox_map_message
> ... at the point of the crash.

Unfortunately I had lurker continue its salvaging and then restarted it,
so I can't provide the information you need. For the next time it
happens, how would you recommend I grab this information from gdb at the
point of crash?

> I just commited a bit of caution in cvs. I am hoping to have it assert
> fail a little earlier so that I can be certain where things are going
> wrong.  After you get those variables, try the latest cvs and see if
> it asserts.

I haven't gotten the variables. Would you like me to go ahead with CVS
anyway?

Thank you, as always.

 --> Jijo

PS- do you have full archives of this list? Sourceforge won't let me
grab the full archives, and I am thinking of putting up
powered-by-lurker archives. ;)

-- 
Federico Sevilla III  : http://jijo.free.net.ph      : When we speak of free
Network Administrator : The Leather Collection, Inc. : software we refer to
GnuPG Key ID          : 0x93B746BE                   : freedom, not price.

Re: [Lurker-users] Lurker 1.0 Survey

[Federico S. I. <ji...@fr...>]

On Thu, Apr 10, 2003 at 11:25:15PM +0200, Wesley W. Terpstra wrote:
> Ok, I am going to finally start work on lurker 1.0.
> 
> There will be sweeping changes in this lurker version, but I need to
> know some things about the current user-base first. I am conducting
> this survey verbally and non-anonymously so that I can get more than a
> simple x users for this, y for that. If your answers are open for
> public debate, reply to the list. Otherwise, reply directly to me.
> 
> After I collect this information, I will post a lurker 1.0
> requirements list and design for further final feedback. After this is
> finalized, I will proceed to implement lurker 0.5, 0.6, ... 0.12 until
> it's solid -> 1.0.

This roadmap sounds really good. Exciting news for the future. :)

> 1.  Does your platform have g++ 3.2?
> 1a. If you do not have g++ 3.2, do you have an ISO C++ conformant compiler?
> 1b. How much pain does setting it up cause you?

I use Debian GNU/Linux and it has G++ 3.2 (at least in Sid).

> 2.  Is 'jam' available for your platform?
>     <http://www.perforce.com/jam/jam.html>
> 2a. How much pain does setting it up cause you?

It seems Debian has a Jam package, as well. I am curious: how much
overhead is using Jam going to remove from your current build system? I
hope Jonas Meurer won't have problems working with Jam for the Debian
package of Lurker.

> 3. Rank the dependent libraries in order of *DEcreasing* pain:
>    libst, libc-client, libxslt1, libiconv
> 3a. Would you rather lurker.tgz include needed libraries?

I'm a spoiled brat with Debian. The current "just lurker, depending on
other libraries" is pretty ok with me, but I'd give my vote on this to
whatever Jonas Meurer has to say.

> 4. Rank these lurker features in *DEcreasing* importance:
>    capacity, threading, caching, search, mime-support, multi-lingual, xslt
>    ... indicate the point where you stop caring.

1. Search
2. Threading
3. Capacity
4. MIME support
5. Caching
[ Don't care ]
6. Multi-lingual
7. XSLT

> 5. Would you prefer lurker to run as a normal CGI or do you prefer it's
>    create-page-on-demand 404 error handler approach?

Whichever allows you to keep your codebase clean.

> 6. Small database size or fast database?

Fast database, as long as the database size is not profanely large vis a
vis the size of the messages stored.

> 7. Back-issue import w/o reimport or date-sorted search?

Having to rebuild the database for back-issues is a hassle, but for the
cleanliness of your codebase and date-sorted searches, and considering
the fact that database rebuilds are getting faster with every point
release, feel free to keep the current system of having to rebuild for
back-issues.

> 8.  Pretty or small html?
> 8a. How big is too big for the output html?
> 8b. Is lynx compatability (like now) important?

The current look is nice, clean, direct, and awesomely easy to navigate.
Prettyness isn't a big issue. Useability is. (Useability doesn't mean
Lynx, but I guess some people will appreciate that.)

> 9. How much RAM is too much for lurker to use?

The memory used indirectly by mmap right now is a bit on the high side,
but I have noticed that it's only noticeable during database rebuilds,
after which the kernel cleans things up so it's ok. For the stuff we
have at marc.free.net.ph, we have 512MB RAM shared with a lot of other
appso. I hope we won't need to upgrade to 1GB or more just to keep
lurker happy...

> 10.  Is cleaning up cached .html important or should I keep all valid html?
> 10a. If clean up: cronjob or daemon? (supposing no normal lurker daemon)

A spider could cause all mail HTMLized. While it's good to have valid
HTML on cache so that other spiders don't cause lurker to do too much
work, it may be a good option to have the cache purged by a cronjob
every now and then.

> 11. Have you ever used lurker's xslt to customize the UI?

Nope. UI's fine as it is.

> 12. Do you believe the majority of your users have an xslt-capable browser?

I don't even know. I haven't looked into XSLT enough... or at all. It
seems most people who use our archives have Mozilla or MSIE.

> 13. What url-scheme for message viewing do you prefer? (bookmarks/google):
> 	message/message-id.xml	<-- current
> 	message/YYYYMMDD_Subject_Author_Name_22.xml
> 	message/34534.xml
> 	other

Message ID is fine, and seems sound because it's constant across
database rebuilds. If 34534.xml will be constant even when we rebuild
and add back-issues then that'll be easier to link to. 

> 14. What should be improved most in lurker? (other than stability)

Stability. ;)

Seriously, next to that, more search options and faster database
rebuilds might be nice, but I'm really quite satisfied with how things
are sans the stability issues.

> 15. Do you know anyone who would like to help with lurker development?
>     In what capacity?
>     ... if the xslt is voted to stay in, I particularily need someone to
>     help with the xml---xslt-->html rendering; lurker needs a sharper look.

I will help with debugging, and maybe later on with the code but I don't
think you need help in that area since you're doing a very good job as
it is.

> 16. Other comments on lurker's future?

Just keep going. We're here to cheer you on. :)

 --> Jijo

-- 
Federico Sevilla III  : http://jijo.free.net.ph      : When we speak of free
Network Administrator : The Leather Collection, Inc. : software we refer to
GnuPG Key ID          : 0x93B746BE                   : freedom, not price.

Re: [Lurker-users] SIGBUS in mbox.c (CVS 20030409)

[Wesley W. T. <we...@te...>]

On Fri, Apr 11, 2003 at 12:49:24PM +0800, Federico Sevilla III wrote:
> Using a copy checked out from CVS on 2003-04-09, I hit SIGBUS in mbox.c
> during a database rebuild from scratch. I hope the backtrace helps fix
> things. If you need more information please let me know.

I need some more information. :-)

> (gdb) run -n
> Starting program: /usr/sbin/lurkerd -n
> 
> Program received signal SIGBUS, Bus error.
> 0x08052dcf in my_mbox_find_special (k=0x806bccd "\nFrom ", s=0x42b0a22c "", e=0x42b0b22c "") at mbox.c:220
> 220     mbox.c: Permission denied.
>         in mbox.c
> (gdb) bt
> #0  0x08052dcf in my_mbox_find_special (k=0x806bccd "\nFrom ", s=0x42b0a22c "", e=0x42b0b22c "") at mbox.c:220
> #1  0x08054654 in lu_mbox_map_message (mbox=0x8073c48, msg=0x4124d920, start=25938120) at mbox.c:1072
> #2  0x08057fe7 in my_service_mbox (h=0x4124d9c0, request=0x4124da05 "m0u...@bi...", ext=0x4124da24 "txt") at service.c:1356
> #3  0x0805b193 in lu_service_connection (fd=0x80b9a00) at service.c:2666
> #4  0x0805caa2 in my_main_handle_client (arg=0x80b9a00) at main.c:137
> #5  0x40019b02 in st_thread_create () from /usr/lib/libst.so.1
> #6  0x000f4240 in ?? ()

This SIGBUS occured while you were opening a message in the browser,
correct? So, it was mid-import and you viewed a message. This should be
ok...

Judging by the code in that region, it has somehow tried to access memory
past the end of the mmap'd mbox. This is odd since I keep a pointer to the
end of the mmap/eof.

If possible, I would love to know the value of variables: 
	s, e in my_mbox_find_special
	start, amt, buf, e, msg->map.size, msg->map.off in lu_mbox_map_message
... at the point of the crash.

I just commited a bit of caution in cvs. I am hoping to have it assert fail
a little earlier so that I can be certain where things are going wrong.
After you get those variables, try the latest cvs and see if it asserts.

---
Wes

Re: [Lurker-users] Lurker 1.0 Survey

[Wesley W. T. <we...@te...>]

On Thu, Apr 10, 2003 at 11:15:13PM -0600, Jamin W. Collins wrote:
> On Thu, Apr 10, 2003 at 11:25:15PM +0200, Wesley W. Terpstra wrote:
> > 7. Back-issue import w/o reimport or date-sorted search?
> 
> Not entirely sure what you're referring to here.

Right now, when you want to import messages that are older than the most
recently imported message, you have to dump the database and start over.

This is because messages are assigned IDs in chronological order, and I
return the results in sorted order based on these IDs. This is why you
always see most recent results first in a search.

If I have to choose between one or the other, which is more important:
	ability to import messages from the past w/o reimport
	searches returning recent messages first

> > 9. How much RAM is too much for lurker to use?
> 
> 32-64 (not entirely sure what it uses now)

This is Mb? (right now it uses nearly exactly 8Mb - always)

> > 14. What should be improved most in lurker? (other than stability)
> 
> DB fault tolerance.  Possibly even with the option to automatically have
> it start from scratch if it can't recover.

... other than stability. :-)

The main things I intend to improve right now (subject to being out-voted):
	a much faster (!!!), 32-bit ok, and transactional db
	using a faster/less-hassles mime parser (mime++)

---
Wes

Re: [Lurker-users] buildling cvs

[Wesley W. T. <we...@te...>]

On Thu, Apr 10, 2003 at 10:42:55PM -0400, Kevin Brosius wrote:
> I looked for libc-client, but I don't see it specifically at
> ftp://ftp.cac.washington.edu/imap/ .  Has it been renamed or moved?

To be honest; I am not really sure.
c-client is ancient and has been integrated in different ways to many
different platforms. I believe imap should be ok.

> I've completed a compile now, but the link is failing like:
> 
> gcc  -g -O2 -Wall   -o lurkerd  config.o decode.o md5.o indexer.o
> summary.o mbox.o search.o service.o expiry.o main.o url.o mailto.o
> quote.o art.o ../common/libcommon.a ../libkap/libkap.a -L/usr/local/lib
> -lst   -lm  

Seems to me you are missing a -lc-client on there.
The undefined references are all about c-client also.

> But that looks like a problem with my configure changes to get
> libc-client to be recognized (no -lc-client on the link line:( ).  I'll
> spend some more time getting this working.  Suggestions welcome :) 

Try: 
LIBS="-lc-client" ./configure ....

> Are you interested in autoconf patches if this can be made to work more
> cleanly on SuSE?

Yes.

---
Wes

[Lurker-users] SIGBUS in mbox.c (CVS 20030409)

[Federico S. I. <ji...@fr...>]

Hi everyone,

Using a copy checked out from CVS on 2003-04-09, I hit SIGBUS in mbox.c
during a database rebuild from scratch. I hope the backtrace helps fix
things. If you need more information please let me know.

(gdb) run -n
Starting program: /usr/sbin/lurkerd -n

Program received signal SIGBUS, Bus error.
0x08052dcf in my_mbox_find_special (k=0x806bccd "\nFrom ", s=0x42b0a22c "", e=0x42b0b22c "") at mbox.c:220
220     mbox.c: Permission denied.
        in mbox.c
(gdb) bt
#0  0x08052dcf in my_mbox_find_special (k=0x806bccd "\nFrom ", s=0x42b0a22c "", e=0x42b0b22c "") at mbox.c:220
#1  0x08054654 in lu_mbox_map_message (mbox=0x8073c48, msg=0x4124d920, start=25938120) at mbox.c:1072
#2  0x08057fe7 in my_service_mbox (h=0x4124d9c0, request=0x4124da05 "m0u...@bi...", ext=0x4124da24 "txt") at service.c:1356
#3  0x0805b193 in lu_service_connection (fd=0x80b9a00) at service.c:2666
#4  0x0805caa2 in my_main_handle_client (arg=0x80b9a00) at main.c:137
#5  0x40019b02 in st_thread_create () from /usr/lib/libst.so.1
#6  0x000f4240 in ?? ()


 --> Jijo


-- 
Federico Sevilla III  : http://jijo.free.net.ph      : When we speak of free
Network Administrator : The Leather Collection, Inc. : software we refer to
GnuPG Key ID          : 0x93B746BE                   : freedom, not price.

[Lurker-users] buildling cvs

[Kevin B. <co...@co...>]

Greetings,
  I've just recently come across lurker, and it looks like a rather nice
archive system.  I'm now trying to get a trial install setup, and ran
into the following build issues.

In looking for libst and libc-client, I wondered which versions are
recommended?  I installed libst-1.4 without much trouble.

I looked for libc-client, but I don't see it specifically at
ftp://ftp.cac.washington.edu/imap/ .  Has it been renamed or moved?  I
started by installing imap and imap-devel (SuSE 8.1), as that provided
libc-client.  However, because the package is named imap, the include
files are in <imap/*.h> rather than <c-client/*.h>.  I worked around
that by modifying 'configure' and lurker/store/mbox.h to use the imap
include files.  Is this reasonable?  I'm unfamiliar with the imap and
c-client libraries, so I don't know if the version in imap is even close
to that expected by lurker.  (However, I noticed later that the ftp site
mentioned above has a 'c-client.tar.Z' which extracts to imap/src/* and
includes some c-client files.  Is this the version lurker uses?

I've completed a compile now, but the link is failing like:

gcc  -g -O2 -Wall   -o lurkerd  config.o decode.o md5.o indexer.o
summary.o mbox.o search.o service.o expiry.o main.o url.o mailto.o
quote.o art.o ../common/libcommon.a ../libkap/libkap.a -L/usr/local/lib
-lst   -lm  
indexer.o: In function `my_indexer_traverse':
/usr/local/src/lurker/lurker/store/indexer.c:187: undefined reference to
`fs_give'
mbox.o: In function `my_mbox_convert_date_field':
/usr/local/src/lurker/lurker/store/mbox.c:605: undefined reference to
`mail_parse_date'
/usr/local/src/lurker/lurker/store/mbox.c:608: undefined reference to
`mail_longdate'
mbox.o: In function `lu_mbox_select_body':
/usr/local/src/lurker/lurker/store/mbox.c:997: undefined reference to
`rfc822_base64'
/usr/local/src/lurker/lurker/store/mbox.c:999: undefined reference to
`rfc822_qprint'
mbox.o: In function `lu_mbox_parse_message':
/usr/local/src/lurker/lurker/store/mbox.c:1130: undefined reference to
`mail_string'
/usr/local/src/lurker/lurker/store/mbox.c:1130: undefined reference to
`mail_string'
/usr/local/src/lurker/lurker/store/mbox.c:1139: undefined reference to
`rfc822_parse_msg_full'


But that looks like a problem with my configure changes to get
libc-client to be recognized (no -lc-client on the link line:( ).  I'll
spend some more time getting this working.  Suggestions welcome :)  Are
you interested in autoconf patches if this can be made to work more
cleanly on SuSE?

-- 
Kevin

[Lurker-users] Lurker 1.0 Survey

[Wesley W. T. <we...@te...>]

Ok, I am going to finally start work on lurker 1.0.

There will be sweeping changes in this lurker version, but I need to know
some things about the current user-base first. I am conducting this survey
verbally and non-anonymously so that I can get more than a simple x users
for this, y for that. If your answers are open for public debate, reply to
the list. Otherwise, reply directly to me.

After I collect this information, I will post a lurker 1.0 requirements list
and design for further final feedback. After this is finalized, I will
proceed to implement lurker 0.5, 0.6, ... 0.12 until it's solid -> 1.0.

If you would like lurker to be useful to you, please let me know:

1.  Does your platform have g++ 3.2?
1a. If you do not have g++ 3.2, do you have an ISO C++ conformant compiler?
1b. How much pain does setting it up cause you?

2.  Is 'jam' available for your platform?
    <http://www.perforce.com/jam/jam.html>
2a. How much pain does setting it up cause you?

3. Rank the dependent libraries in order of *DEcreasing* pain:
   libst, libc-client, libxslt1, libiconv
3a. Would you rather lurker.tgz include needed libraries?

4. Rank these lurker features in *DEcreasing* importance:
   capacity, threading, caching, search, mime-support, multi-lingual, xslt
   ... indicate the point where you stop caring.

5. Would you prefer lurker to run as a normal CGI or do you prefer it's
   create-page-on-demand 404 error handler approach?

6. Small database size or fast database?

7. Back-issue import w/o reimport or date-sorted search?

8.  Pretty or small html?
8a. How big is too big for the output html?
8b. Is lynx compatability (like now) important?

9. How much RAM is too much for lurker to use?

10.  Is cleaning up cached .html important or should I keep all valid html?
10a. If clean up: cronjob or daemon? (supposing no normal lurker daemon)

11. Have you ever used lurker's xslt to customize the UI?

12. Do you believe the majority of your users have an xslt-capable browser?

13. What url-scheme for message viewing do you prefer? (bookmarks/google):
	message/message-id.xml	<-- current
	message/YYYYMMDD_Subject_Author_Name_22.xml
	message/34534.xml
	other

14. What should be improved most in lurker? (other than stability)

15. Do you know anyone who would like to help with lurker development?
    In what capacity?
    ... if the xslt is voted to stay in, I particularily need someone to
    help with the xml---xslt-->html rendering; lurker needs a sharper look.

16. Other comments on lurker's future?

---
Wesley W. Terpstra <we...@te...>

Re: [Lurker-users] Debugging signal 11 program faults

[Federico S. I. <ji...@fr...>]

On Sun, Apr 06, 2003 at 03:03:14PM +0200, Wesley W. Terpstra wrote:
> This is irrelevant; don't change your filesystems. I am positive it is
> a bug in lurker from the new mbox added, and I believe it has now been
> corrected.

I built a local Debian package with a CVS checkout made on 2003-04-07,
and was able to rebuild my databases from scratch. Thank you very much
for the quick reply with a fix in CVS, to boot.

I had opened a bug in the Debian BTS with bug number 187507. Jonas can
close this when the next release (with the CVS fix) is made.

I don't know if it's XFS, the changes in lurker, or the combination of
both, but today's rebuild is progressing significantly faster than
previous rebuilds (which I made using 0.1f with ext3). I don't have
actual time of previous rebuilds, but I'd wager that today's rebuild
will finish in half the time it used to take. Awesome, simply awesome.
:)

 --> Jijo

-- 
Federico Sevilla III  : http://jijo.free.net.ph      : When we speak of free
Network Administrator : The Leather Collection, Inc. : software we refer to
GnuPG Key ID          : 0x93B746BE                   : freedom, not price.

Re: [Lurker-users] Debugging signal 11 program faults

[Wesley W. T. <we...@te...>]

On Wed, Apr 02, 2003 at 04:42:58PM +0800, Federico Sevilla III wrote:
> <stuff about the filesystem>

This is irrelevant; don't change your filesystems. I am positive it is a bug
in lurker from the new mbox added, and I believe it has now been corrected.

> The Lurker database I was previously using was built when the system was
> running ext3, and seemed to be ok. Recently I purged the database to add
> some "back-issues" of the linux-xfs mailing list to the archives, and
> now cannot rebuild the database. Lurker keeps getting a signal 11
> program fault, traps it, and syncs the database to disk. This continues
> to happen when I rerun lurkerd, whether I purge the database or let it
> resume where it left off.

It sounds like one of the back-issue messages you added causes lurker to
segfault; probably corrupt in a way I don't handle.

> I am using the lurkerd_0.1f-5 Debian package. I rebuilt the package with
> only one change: I added "-g" to the CFLAGS to allow gdb to do tracing.
> I could not run lurkerd from gdb, because it would just exit normally
> without doing anything. So I started lurkerd the standard Debian way,
> which makes it run as the www-data user, then attached to this process
> manually using gdb, also as the www-data user.

This is because lurker detaches at startup; add the -n option:
gdb$ run -n

> First I got a lot of messages[1] about the attachment process which
> seemed to work fine, although there was a permission denied error at
> mbox.c line 220 for which I have a backtrace[2]. I made gdb continue,
> and it took awhile, seemingly doing its real work. Then I hit the
> SIGSEGV[3], at line 172 of indexer.c, for which a backtrace is also
> available[4].

This is useful; looking into it... My line 172 is empty. :-)

I presume it is the:
	my_indexer_traverse(in, body->nested.msg->body);
line?

Sounds like there is no body->nested->msg->body.
Which means that the email has a corrupt embedded email.
I have added a check to ignore messages in this case.

Please try the latest cvs; I believe I have now fixed this bug.

-- 
Wesley W. Terpstra <we...@te...>

Re: [Lurker-users] Debugging signal 11 program faults

[Federico S. I. <ji...@fr...>]

As a followup to my message:

I decided to run tests by reversing the last change I did, that change
being adding the historical archives of the linux-xfs mailing list,
which had some data converted from Eudora mboxes usinge Eudora2Mbox.
Unfortunately that didn't fix things. lurkerd continues to hit a signal
11 at line 172 of indexer.c.

The only other thing I can reverse is going back to ext3, but I can't
afford to do that anymore, nor do I want to. Should be a great
opportunity to get lurker working fine with XFS, as well, since XFS
provides pretty good performance benefits when dealing with large files,
like the largish mboxes that I'm beginning to accumulate for the
archives.

I hope someone can help. Thanks in advance.

 --> Jijo

-- 
Federico Sevilla III  : http://jijo.free.net.ph      : When we speak of free
Network Administrator : The Leather Collection, Inc. : software we refer to
GnuPG Key ID          : 0x93B746BE                   : freedom, not price.

[Lurker-users] Debugging signal 11 program faults

[Federico S. I. <ji...@fr...>]

Hi everyone,

I have been running Lurker for quite awhile now to handle message
archives at <http://marc.free.net.ph/>. I had originally been using XFS,
then shifted to ext3, and then back.

The Lurker database I was previously using was built when the system was
running ext3, and seemed to be ok. Recently I purged the database to add
some "back-issues" of the linux-xfs mailing list to the archives, and
now cannot rebuild the database. Lurker keeps getting a signal 11
program fault, traps it, and syncs the database to disk. This continues
to happen when I rerun lurkerd, whether I purge the database or let it
resume where it left off.

I am using the lurkerd_0.1f-5 Debian package. I rebuilt the package with
only one change: I added "-g" to the CFLAGS to allow gdb to do tracing.
I could not run lurkerd from gdb, because it would just exit normally
without doing anything. So I started lurkerd the standard Debian way,
which makes it run as the www-data user, then attached to this process
manually using gdb, also as the www-data user.

First I got a lot of messages[1] about the attachment process which
seemed to work fine, although there was a permission denied error at
mbox.c line 220 for which I have a backtrace[2]. I made gdb continue,
and it took awhile, seemingly doing its real work. Then I hit the
SIGSEGV[3], at line 172 of indexer.c, for which a backtrace is also
available[4].

These have been completely reproducible lately. Without purging the
database, I ran lurkerd again then attached to the running process using
gdb. After awhile, the process ran into SIGSEGV again at line 172 of
indexer.c, information[5] on which I am providing in case it can help.

I have checked, and the mboxes lurker is reading are readable by
www-data. Please let me know what other information I may provide to
help in the debugging of this problem that is keeping me from providing
the archives using lurker.

Thank you very much for your time.

 --> Jijo


[1] Messages during attachment:

    This GDB was configured as "i386-linux"...
    Attaching to program: /usr/sbin/lurkerd, process 5768
    Reading symbols from /usr/lib/libst.so.1...done.
    Loaded symbols for /usr/lib/libst.so.1
    Reading symbols from /usr/lib/libc-client.so.2003debian...done.
    Loaded symbols for /usr/lib/libc-client.so.2003debian
    Reading symbols from /lib/libm.so.6...done.
    Loaded symbols for /lib/libm.so.6
    Reading symbols from /usr/lib/i686/cmov/libssl.so.0.9.7...done.
    Loaded symbols for /usr/lib/i686/cmov/libssl.so.0.9.7
    Reading symbols from /lib/libc.so.6...done.
    Loaded symbols for /lib/libc.so.6
    Reading symbols from /lib/libpam.so.0...done.
    Loaded symbols for /lib/libpam.so.0
    Reading symbols from /lib/libdl.so.2...done.
    Loaded symbols for /lib/libdl.so.2
    Reading symbols from /usr/lib/i686/cmov/libcrypto.so.0.9.7...done.
    Loaded symbols for /usr/lib/i686/cmov/libcrypto.so.0.9.7
    Reading symbols from /usr/lib/libgssapi_krb5.so.2...done.
    Loaded symbols for /usr/lib/libgssapi_krb5.so.2
    Reading symbols from /usr/lib/libkrb5.so.3...done.
    Loaded symbols for /usr/lib/libkrb5.so.3
    Reading symbols from /usr/lib/libk5crypto.so.3...done.
    Loaded symbols for /usr/lib/libk5crypto.so.3
    Reading symbols from /lib/libcom_err.so.2...done.
    Loaded symbols for /lib/libcom_err.so.2
    Reading symbols from /lib/ld-linux.so.2...done.
    Loaded symbols for /lib/ld-linux.so.2
    Reading symbols from /lib/libresolv.so.2...done.
    Loaded symbols for /lib/libresolv.so.2
    Reading symbols from /usr/lib/gconv/ISO8859-1.so...done.
    Loaded symbols for /usr/lib/gconv/ISO8859-1.so
    0x08052dc3 in my_mbox_find_special (k=0x806bbad "\nFrom ", 
        s=0x41100000 "gin except root.\n> Removing the \"*\" tells the system that the password is disabled for that login.\n> I see saw this as a security problem if I removed the \"*\" so I tried to login\n> as \"+\" - I wouldn't"..., 
       e=0x41100ae0 "13:32:16 -0500\nFrom: Alan Cox <al...@cy...>\nMessage-Id: <199...@sn...>\nSubject: Re: psaux / watchdog combination problem ..\nTo: dr...@rf... (Dan McLaughlin)\nDat"...) at mbox.c:220
    220     mbox.c: Permission denied.
            in mbox.c


[2] Backtrace of permission denied error in mbox.c line 220:

    (gdb) bt
    #0  0x08052dc3 in my_mbox_find_special (k=0x806bbad "\nFrom ", 
        s=0x41100000 "gin except root.\n> Removing the \"*\" tells the system that the password is disabled for that login.\n> I see saw this as a security problem if I removed the \"*\" so I tried to login\n> as \"+\" - I wouldn't"..., 
        e=0x41100ae0 "13:32:16 -0500\nFrom: Alan Cox <al...@cy...>\nMessage-Id: <199...@sn...>\nSubject: Re: psaux / watchdog combination problem ..\nTo: dr...@rf... (Dan McLaughlin)\nDat"...) at mbox.c:220
    #1  0x08054530 in lu_mbox_map_message (mbox=0x8073bdc, msg=0x8073c00, start=2554592) at mbox.c:1040
    #2  0x08052fc7 in my_mbox_process_mbox (mbox=0x8073bdc, list=0x8073028, stamp=826782874) at mbox.c:314
    #3  0x08054030 in my_mbox_watch (arg=0x0) at mbox.c:836
    #4  0x4001ab02 in st_thread_create () from /usr/lib/libst.so.1
    #5  0xbffffa84 in ?? ()
    #6  0x00000000 in ?? ()


[3] SIGSEGV at indexer.c:

    Program received signal SIGSEGV, Segmentation fault.
    0x08050501 in my_indexer_traverse (in=0x403f2dc0, body=0x80b6090) at indexer.c:172
    172     indexer.c: Permission denied.
            in indexer.c


[4] Backtrace of permission denied at indexer.c line 172:

    (gdb) bt
    #0  0x08050501 in my_indexer_traverse (in=0x403f2dc0, body=0x80b6090) at indexer.c:172
    #1  0x0805057f in my_indexer_traverse (in=0x403f2dc0, body=0x80b6a08) at indexer.c:195
    #2  0x08050baa in lu_indexer_message (body=0x403f2dc0, stamp=852695640, reply_id=0x403f2b50 "") at indexer.c:443
    #3  0x08053634 in my_mbox_process_mbox (mbox=0x8073c28, list=0x8073028, stamp=852695640) at mbox.c:496
    #4  0x08054030 in my_mbox_watch (arg=0x0) at mbox.c:836
    #5  0x4001ab02 in st_thread_create () from /usr/lib/libst.so.1
    #6  0x4001aa2a in st_thread_create () from /usr/lib/libst.so.1
    #7  0x00000000 in ?? ()


[5] SIGSEGV at indexer.c after rerunning gdb with the salvaged db from
    the previous run:

    Program received signal SIGSEGV, Segmentation fault.
    0x08050501 in my_indexer_traverse (in=0x403f2dc0, body=0x80a2288) at indexer.c:172
    172     indexer.c: Permission denied.
            in indexer.c
    (gdb) bt
    #0  0x08050501 in my_indexer_traverse (in=0x403f2dc0, body=0x80a2288) at indexer.c:172
    #1  0x0805057f in my_indexer_traverse (in=0x403f2dc0, body=0x80a2b90) at indexer.c:195
    #2  0x08050baa in lu_indexer_message (body=0x403f2dc0, stamp=856902135, reply_id=0x403f2b50 "") at indexer.c:443
    #3  0x08053634 in my_mbox_process_mbox (mbox=0x8073c28, list=0x8073028, stamp=856902135) at mbox.c:496
    #4  0x08054030 in my_mbox_watch (arg=0x0) at mbox.c:836
    #5  0x4001ab02 in st_thread_create () from /usr/lib/libst.so.1
    #6  0x4001aa2a in st_thread_create () from /usr/lib/libst.so.1
    #7  0x00000000 in ?? ()



-- 
Federico Sevilla III  : http://jijo.free.net.ph      : When we speak of free
Network Administrator : The Leather Collection, Inc. : software we refer to
GnuPG Key ID          : 0x93B746BE                   : freedom, not price.