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): 2001a How reproducible: Always 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 accessed. Additional info:
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 development team?
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 in bugzilla. 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.