If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

warning C4013: 'malloc_usable_size' undefined in sqlite3.c

NEW
Unassigned

Status

()

Toolkit
Storage
5 years ago
2 years ago

People

(Reporter: RyanVM, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
All
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
Just noticed this today when working on updating SQLite to 3.7.12. Not sure if it's anything serious, but worth filing anyway.

sqlite3.c
e:/builds/moz2_slave/m-in-w32/build/db/sqlite3/src/sqlite3.c(15335) : warning C4013: 'malloc_usable_size' undefined; assuming extern returning int
It actually doesn't matter at all. The code that calls malloc_usable_size is never used because we register our own memory methods.
(In reply to Mike Hommey [:glandium] from comment #1)
> It actually doesn't matter at all. The code that calls malloc_usable_size is
> never used because we register our own memory methods.

which means we can probably get rid of http://mxr.mozilla.org/mozilla-central/source/db/sqlite3/src/Makefile.in#154 , which would remove the warning.
On the other hand, there's bug 719579... is nss using sqlite before we initialize it from storage?
(In reply to Mike Hommey [:glandium] from comment #2)
> which means we can probably get rid of
> http://mxr.mozilla.org/mozilla-central/source/db/sqlite3/src/Makefile.in#154
> , which would remove the warning.

we can't get rid of that, otherwise we end up using _msize and the build crashes badly on win64 (it ends up using _msize instead of malloc_usable_size but then later tries to alloc with our custom allocator thinking we used our malloc_usable_size, not _msize).
(In reply to Marco Bonardo [:mak] from comment #4)
> (In reply to Mike Hommey [:glandium] from comment #2)
> > which means we can probably get rid of
> > http://mxr.mozilla.org/mozilla-central/source/db/sqlite3/src/Makefile.in#154
> > , which would remove the warning.
> 
> we can't get rid of that, otherwise we end up using _msize and the build
> crashes badly on win64 (it ends up using _msize instead of
> malloc_usable_size but then later tries to alloc with our custom allocator
> thinking we used our malloc_usable_size, not _msize).

The only way i can see for _msize to be called is if sqlite calls its memsize function before we set our memory handling functions. This also means that it may be allocating memory before we set our memory handling functions. I'd say we should try to avoid that.
(Reporter)

Comment 6

2 years ago
This warning still occurs, not sure based on the last comments in this bug whether this is something we need to actively worry about or not, though. I'm guessing not given how long it's sat for, though :)
You need to log in before you can comment on or make changes to this bug.