|
Good morning,
I have been checking the Cyrus IMAP 2.3.19 and 2.3.18 code because
I have observed some issues in UID SORT commands in the IMAP
protocol. When performing a command
like ". UID SORT (SIZE) US-ASCII ALL TEXT avanzada" in a mailbox
where matches were found caused you to obtain in a debug (or non
debug I think) log the following entry :
Oct 31 09:17:21 hostname master[78064]: process 78268 exited,
signaled to death by 11
Lines like this are seen when a process has been signaled by the
kernel with signal 11. Have been reading this signal is sent to a
proccess when it performs an unauthorized memory
access attemp (an out of the own variable, pointer... etc, storage
room). After debugging the code with GDB and doing several checks,
have seen the issue came from the byte2search()
function when a piece of the string s->substr was trying to be
stored in b. Concretely the third if in the loop :
for (i = 0, cur = 0; i < s->max_start; i++) {
/* no more active offsets */
if (s->starts[i] == -1)
break;
/* if we've passed one that's not ongoing, copy back */
if (cur < i) {
s->starts[cur] = s->starts[i];
}
/* check that the substring is still maching */
if (b == s->substr[s->offset - s->starts[i]]) {
The issue was caused there because s->starts[i] in this place,
was not being able to be accesed because it was pointing to to
data outside s->starts. After searching where this array was
being initialized
and it's memory allocated (which was in search_init function), I
tried to allocate 10 bytes more for that pointer. After doing it,
there were no more issues. So I tried allocating just one byte
more which it seemed
to be enough too (at least for the patterns I have searched for).
At this moment I understood this pointer (s->starts which was a
search_state->substr pointer inside the search_state structure)
was not having
enough room for all the content needed to be stored, or at least
accesed when calling it. I checked then the code of Cyrus 2.3.18
and 2.3.19 but didn't see any kind of differences in the part of
the memory
allocation (in search_init()) or usage (in bytesearch) for
s->starts. I deciced to check Cyrus 2.4 code and I saw it's
room was being allocated the following way :
s->starts = xmalloc(s->max_start * sizeof(size_t));
instead of that in 2.3 was done :
s->starts = xmalloc(s->max_start * sizeof(int));
So I understood s->starts should be allocated to the size of a
size_t type defined variable size, instead to the size of an
integer variable n times. After replacing it, has seen
definitively all seemed to be
working. So wouldn't Cyrus 2.3 sources have this allocation in
search_init done with sizeof(size_t) instead of the sizeof(int)?.
I think this is important because else, when the first character
of a
pattern is repeated more than one time, the pattern has a would
say patlen of 8-9 bytes and matches exist in the mailbox, that
search would end up with a proccess died due to a signal 11.
My env is FreeBSD RELENG_9_0 OS with a Cyrus 2.3.18_1 port. Am I
wrong, shouldn't that allocation be changed?.
Thanks a lot for your time,
Best regards,
--
Egoitz Aurrekoetxea
Departamento de sistemas
944 209 470
Parque Tecnológico. Edificio 103
48170 Zamudio (Bizkaia)
Antes de imprimir este correo
electrónico piense si es necesario hacerlo.
|
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
