Red Hat Bugzilla – Bug 184296
mailx overflow of short used to hold message length and message block pointers.
Last modified: 2007-11-30 17:07:23 EST
Description of problem:
as per https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=58672
Version-Release number of selected component (if applicable):
ALL releases of RHEL to date
Steps to Reproduce:
1.Either create a message with more lines than a short, or,
2.Create many messages such that the amount of data is greater than a short
Either bad display of messages, or a fseek() panic, etc.
Should display mail correctly
Additional info: Has been fixed in FC for some time, and the bugfix has been in
bugzilla for even longer. The patch in referenced bugzilla works perfectly.
According to ug #58672 patch exists - easy fix. This is the only bug for mailx
so far, please feel free to reject it.
Excuse me for my ignorance, but what exactly does 'reject it' mean? Why is it
considered acceptable to leave a bug in RHEL4 that has been fixed upstream for
This has actually bitten us in production and I suppose we could log the job as
a support call, but really, why bother with Bugzilla at all then?
bug #58672 notes that this was fixed in 2004, and indeed, it does appear fixed
in FC4 and on. This seems like a good candidate for a quarterly update.
The problem is that we have to mediate the amount of change introduced in the
already released versions of RHEL which are used in production environments
Every change bears the risk of regression and side-effects and also our
resources are limited so that we need to prioritize components we change in
order to be able to focus on the right problems.
The prioritization amongst other factors is based on the severity of the
problem, the broadness of its impact, customer issues reported via our support
organization and the total number of issues against a specific component (e.g.
in this case mailx).
The comment about "rejecting" has to be seen in this context: we have no other
issues open for mailx in RHEL3, non via support escalation, and we have no other
data justifying a high prioritization. So for a regular update release we would
not prioritize mailx very high and it probably would be deferred to a later
release because components with more critical isues would take priority. In the
later release we would then re-prioritize. Especially if there is a number of
open issues we would address approve updating the component.
Now for the specific case of RHEL3, we are beyond the Full Support and in the
Deployment phase of it's life cycle. U8 already was an extention of that phase
and now RHEL3 is in transition to the Maintenance phase. So at this poing we are
additionally reducing the change to be introduced
Now we indeed ask our customers to report their production issues via our
support organization by phone, email or the support web interface (partly
depending on the SLA level) instead of directly filing in Bugzilla.
Bugzilla is a development tool, not a support tool. It is correct that Bugzilla
plays an important role in our processes and all bugs go via Bugzilla. Red Hat
actually is working on making more of the bugs we are working on publicly
visible in Bugzilla as they are referenced in the errata. But in order to ensure
the right prioritization, customer issues need to come via the support organization.
I hope that explains a bit what's going on.
I do not see a way we can fix this mailx issue in RHEL 3.9.
One little clarification: we actually ask customers to always report issues via
the support organization. - Not only now.
Product Management has reviewed and declined this request. You may appeal this
decision by reopening this request.
Errr, okay, that long message is nice for RHEL3. However, this issue also exists
in RHEL4, as noted in the comments above. Moving to RHEL4 and reopening.
*** This bug has been marked as a duplicate of 184139 ***
I am astounded by this thread. How is anyone helped by us logging a formal
support call for this trivial fix? Will RHEL5 also have this bug when it is
released? Does it not bother anyone that this problem is an overflow?
(hello!!!!???) How does marking this as a duplicate of the CLOSED Red Hat 7.1(!)
bug help to resolve it for RHEL4?
Crazy. I don't understand why *anyone* in the public would bother using Bugzilla
when the response is, basically, "we can't be bothered".
Anyway, I'm off to log a formal support request for a RHEL4 bug that is
affecting us reading our mail.
Hmmm. There seems to be an advisory which fixes bug #18413
and this is marked as a duplicate of that.
However, that seems to have been only put out as an update for "Other", not as
an actual RHEL 4 update -- weird.
Hmm, weird, somehow I ended up at the RedHat 7.1 entry when I clicked the
'duplicate' link instead of the RHEL4 one with the errata referenced. Odd.
Anyhow, nice to see it's been/being fixed - even if it hasn't been released
officially for RHEL4 yet...