Red Hat Bugzilla – Bug 76392
imap's "popd" (and "pine") crashes when /etc/c-client.cf file configures a black-box-directory
Last modified: 2007-04-18 12:47:49 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910
Description of problem:
"popd" and "pine" both crash with a "Segmentation fault" if the file
/etc/c-client.cf exists and includes the line "set black-box-directory
/var/folders" (or indeed: any directory name).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.create /etc/c-client.cf and type the following..
I accept the risk
set black-box-directory /var/folders
set hide-dot-files 1
2. Create the directory /var/folders/<username> and make readable/writable by
that user (777 will do for test purposes).
3 Login is <username> and run "pine" - Seg fault results
4. Try a pop3 session for the user. For example .. telnet localhost 110
Type "user <username>\n" Then "pass <password>\n" - session is terminated by
the popd server.
Actual Results: pine and popd both crash with "segmentation fault"
Expected Results: Pine and popd should continue to run and allow mail to be
Correction: The crash occurrs if the user's directory DOES NOT exist.
Have you reported this problem also to the upstream imap/pine/c-client
No I havent. Is this something *I* should do, or does RedHat liase with
project teams directly?
Depends on how fast you would like the problem investigated and/or
fixed. Right now you've reached one developer whom is not part of the
pine/imap development team, and is largely unfamiliar with the source
code specifically. While I can attempt to reproduce the problem, and
if it does occur, I can attempt to debug and/or fix it, it is a huge
waste of my resources to troubleshoot every single bug that gets reported
I have to look at each bug reported and decide just how huge a problem
the person is reporting and weigh it into the prioritization of other
bugs that have been reported as I allocate my time to troubleshooting
and debugging the plethora of open bug reports assigned to me. Every
bug that gets reported to the official upstream maintainers of a given
source code package by the bug reporter, maintains a two way communication
between the person experiencing the problem, and the developer, or
development team of numerous developers of whom are very familiar with
the code they have written. In short, reporting the problem to the
people who wrote the code, is the fastest possible way to get an answer
to a suspected problem, be it a bug fix, workaround, patch, or indication
that the problem isn't a bug, or possibly some other indication.
Since you're the first to mention this problem, and since I consider
that if it is in fact a legitimate bug, it likely only affects an
extremely small portion of our userbase - possibly even just you.
As such, I am very inclined to give it a very low priority compared
to the other 300+ bugs I have assigned to me which affect a much
much larger portion of users.
Also, if you do report the problem upstream, and do get an answer back,
and an upstream developer provides a patch or solution, it very well
could get into the next official release or erratum, even if it isn't
specifically considered a showstopper or high priority bug/problem.
In some cases, a developer here at Red Hat will discuss a reported
problem with upstream developers, and at other times, we will refer
the bug reporter to do so themselves. So yes, I'd prefer it if you
report this directly to the University of Washington yourself, and
then provide an update here with the feedback they provide. That
saves me a lot of time from playing middleman between the bug reporter
and the upstream developers - or possibly chasing a red herring.
Ok - I'll report to the authors, and get back to you with feedback. Thanks for
taking the time to respond.