You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
1
(2) |
2
(6) |
3
|
4
|
|
5
|
6
(3) |
7
|
8
|
9
|
10
|
11
(4) |
|
12
(6) |
13
(6) |
14
(17) |
15
(1) |
16
(4) |
17
(6) |
18
|
|
19
(5) |
20
(7) |
21
(3) |
22
(8) |
23
(4) |
24
(8) |
25
(2) |
|
26
(1) |
27
(19) |
28
(5) |
29
(3) |
30
(11) |
31
(6) |
|
|
From: John R. <jr...@bi...> - 2009-07-20 04:13:41
|
> Is this info specific to Linux/glibc? AFAICT sbrk/brk > isn't even POSIX, which makes it even harder to determine what it > should do. sbrk and brk are not POSIX. However, any system that is a derivative of *nix has sbrk and brk because there are too many softwares (such as the Bourne shell) which rely on the traditional memory map (.text, .data+.bss, stack) and the existence of sbrk/brk. A key property of sbrk/brk is that new whole pages that are supplied by the operating system *do* get initialized to zero. Memcheck must support and honor this property. -- John Reiser, jreiser@BitWagon.com |
|
From: Nicholas N. <n.n...@gm...> - 2009-07-20 03:42:36
|
On Sat, Jul 18, 2009 at 12:55 AM, John Reiser<jr...@bi...> wrote: > Nicholas Nethercote wrote: > > 0) sbrk() can *decrease* process address space. No zero fill is done > for a decrease, not even the fragment on the high end of the last page > that is beyond the new highest address. For maximum safety and > portability, then the bytes in the last page that reside above [the new] > sbrk(0) should be considered to be uninitialized, but in practice > it is exceedingly likely that they will retain their previous contents. > > 1) If an increase is large enough to require new whole pages, > then those new whole pages (like all new pages) are zero-filled > by the operating system. So if sbrk(0) already is page aligned, > then sbrk(PAGE_SIZE) *does* zero-fill the new memory. > > 2) Any increase that lies within an existing allocated page > is not changed. So if (x= sbrk(0)) is not page aligned, then > sbrk(PAGE_SIZE) yields ((PAGE_SIZE -1) & -x) bytes which > keep their existing contents, and an additional PAGE_SIZE > bytes which are zeroed. ((PAGE_SIZE -1) & x) of them are > "covered" by the sbrk(), and the rest of them come along for > the ride because the operating system deals only in whole pages. > Again, for maximum safety and portability, then anything that > lives above [the new] sbrk(0) should be considered uninitialized, > but in practice will retain previous contents [zero in this case.] > > Also remember that sbrk(...) can fail :-) Thanks, John. Is this info specific to Linux/glibc? AFAICT sbrk/brk isn't even POSIX, which makes it even harder to determine what it should do. Nick |
|
From: Ruth Ivimey-C. <Rut...@iv...> - 2009-07-19 22:32:24
|
On Sunday 19 July 2009, Christoph Bartoschek wrote:
> the following method is missing:
>
> virtual InstrumentInterface::~InstrumentInterface() {}
>
> Include this method and it should work.
Thanks, it did :-) :-)
Can you explain, though, why the symptoms were as seen.. it seems very obscure to me ?
Ruth
--
Engineer, Author and Webweaver
|
|
From: Christoph B. <bar...@or...> - 2009-07-19 22:23:45
|
Hi,
the following method is missing:
virtual InstrumentInterface::~InstrumentInterface() {}
Include this method and it should work.
Christoph
|
|
From: Christoph B. <bar...@or...> - 2009-07-19 22:15:39
|
Hi,
could you please show the class InstrumentDTP41? Is multiple interitance
involved?
Please also show InstrumentInterface.
Christoph
Am Sonntag, 19. Juli 2009 schrieb Ruth Ivimey-Cook:
> Folks,
>
> I'm hoping you can help. I'm writing a Qt4 program that uses the qt
> plugin interface to implement loadable "instruments" reflecting
> different hardware options. I use the Qt plugin interface to list,
> create and delete instruments implemented by each plugin file.
>
> The plugin creates the instrument fine, and the main program gets back
> the pointer that "new" returned (as can be seen below in the
> non-valgrind text: "New DTP" is in the plugin, "Created instrument" is
> in the main program. The main program then deletes the instrument
> "Deleting instrument"(by calling into the plugin again) and you can see
> that the address remains the same "Delete DTP". I am at a loss as to why
> valgrind (and the MS heap code) has "forgotten" this address ... it now
> thinks (see line 1/2 way down log) that the original block address,
> displayed here as 0x52990a0, was 0x5299090!
>
> This log is from amd64/Fedora 10/valgrind 3.4.1. I've also tried this
> code on 32-bit WinXP and on 64-bit Vista, they all fail, so something
> bad is happening, but what? I tried a valgrind with a MC_MALLOC_REDZONE
> size of 64 bytes to see if that changed anything, but it didn't show
> anything different.
>
> After the valgrind log entry I have appended code snippets: more on
> request.
>
> New DTP @ 0x52990a0
>
> Created instrument @ 0x52990a0 plugin @ 0xb398420
>
> Deleting instrument @ 0x52990a0 plugin @ 0xb398420
>
> Delete DTP @ 0x52990a0
>
> ==23127==
>
> ==23127== Invalid free() / delete / delete[]
>
> ==23127== at 0x4A05E4D: operator delete(void*)
> (vg_replace_malloc.c:342)
> ==23127== by 0xB44772E:
> PluginDTP41::deleteInstrument(InstrumentInterface*) (gl_dtp41.cpp:33)
>
> ==23127== by 0x43D674: SelectDevice::updateDeviceOptions()
> (selectdevice.cpp:70)
> ==23127== by 0x443CFC: SelectDevice::qt_metacall(QMetaObject::Call,
> int, void**) (moc_selectdevice.cpp:71)
> ==23127== by 0x3F3D559421: QMetaObject::activate(QObject*, int, int,
> void**) (in /usr/lib64/libQtCore.so.4.5.1)
> ==23127== by 0x3F4B14A440: QComboBox::currentIndexChanged(int) (in
> /usr/lib64/libQtGui.so.4.5.1)
> ==23127== by 0x3F4B14CAAB: (within /usr/lib64/libQtGui.so.4.5.1)
>
> ==23127== by 0x3F4B14E0D0: (within /usr/lib64/libQtGui.so.4.5.1)
>
> ==23127== by 0x3F4B14E21C: QComboBox::setCurrentIndex(int) (in
> /usr/lib64/libQtGui.so.4.5.1)
> ==23127== by 0x3F4B15300A: QComboBox::qt_metacall(QMetaObject::Call,
> int, void**) (in /usr/lib64/libQtGui.so.4.5.1)
> ==23127== by 0x3F3D559421: QMetaObject::activate(QObject*, int, int,
> void**) (in /usr/lib64/libQtCore.so.4.5.1)
> ==23127== by 0x3F3D58FE13:
> QAbstractItemModel::rowsInserted(QModelIndex const&, int, int) (in
> /usr/lib64/libQtCore.so.4.5.1)
>
> ==23127== Address 0x52990a0 is 16 bytes inside a block of size 96
> alloc'd
> ==23127== at 0x4A0700C: operator new(unsigned long)
> (vg_replace_malloc.c:230)
> ==23127== by 0xB4473A4: PluginDTP41::createInstrument(QString,
> TargetDefBase const*) const (gl_dtp41.cpp:25)
> ==23127== by 0x43CA8C: SelectDevice::CreateNewInstrument()
> (selectdevice.cpp:43)
> ==23127== by 0x43D29F: SelectDevice::updateDeviceOptions()
> (selectdevice.cpp:62)
> ==23127== by 0x443CFC: SelectDevice::qt_metacall(QMetaObject::Call,
> int, void**) (moc_selectdevice.cpp:71)
> ==23127== by 0x3F3D559421: QMetaObject::activate(QObject*, int, int,
> void**) (in /usr/lib64/libQtCore.so.4.5.1)
> ==23127== by 0x3F4B14A440: QComboBox::currentIndexChanged(int) (in
> /usr/lib64/libQtGui.so.4.5.1)
> ==23127== by 0x3F4B14CAAB: (within /usr/lib64/libQtGui.so.4.5.1)
> ==23127== by 0x3F4B14E0D0: (within /usr/lib64/libQtGui.so.4.5.1)
> ==23127== by 0x3F4B14E21C: QComboBox::setCurrentIndex(int) (in
> /usr/lib64/libQtGui.so.4.5.1)
> ==23127== by 0x3F4B15300A: QComboBox::qt_metacall(QMetaObject::Call,
> int, void**) (in /usr/lib64/libQtGui.so.4.5.1)
> ==23127== by 0x3F3D559421: QMetaObject::activate(QObject*, int, int,
> void**) (in /usr/lib64/libQtCore.so.4.5.1)
>
>
> Code in the main program that is calling createInstrument and
> deleteInstrument:
> ------------------------------------------------------
> void SelectDevice::updateDeviceOptions(void)
> {
> if (instrument)
> {
> currentPlugin->deleteInstrument(instrument);
> qDebug() << "Deleting instrument @" << instrument << " plugin @"
> << currentPlugin;
> instrument = NULL;
> }
>
> m_ui->cbPort->clear();
> knownPortTypes.clear();
>
> // create an instrument so as to fetch the valid port types for it...
> instrument = CreateNewInstrument();
> qDebug() << "Created instrument @" << instrument << " plugin @" <<
> currentPlugin;
> if (instrument)
> {
> knownPortTypes = instrument->possiblePorts();
> qDebug() << "Deleting instrument @" << instrument << " plugin @"
> << currentPlugin;
> currentPlugin->deleteInstrument(instrument);
> instrument = NULL;
> m_ui->cbPort->addItems(knownPortTypes);
> }
> }
> ------------------------------------------------------
>
> Code in the plugin that creates/deletes objects:
> ------------------------------------------------------
> InstrumentInterface *PluginDTP41::createInstrument(QString plugin, const
> TargetDefBase *theTarget) const
> {
> // no need to check "plugin" string at present.
> InstrumentInterface *inst = new InstrumentDTP41(theTarget);
> qDebug() << "New DTP @" << inst;
> return inst;
> }
>
> void PluginDTP41::deleteInstrument(InstrumentInterface *inst)
> {
> qDebug() << "Delete DTP @" << inst;
> delete inst;
> }
> ------------------------------------------------------
>
> Finally code in the plugin that is called in the middle:
> ------------------------------------------------------
> InstrumentDTP41::InstrumentDTP41(const TargetDefBase *theTarget)
>
> : InstrumentBase(theTarget)
>
> {
> instrumentName = "DTP-41";
> srand( (unsigned)time( NULL ) );
> }
>
> InstrumentDTP41::~InstrumentDTP41(void)
> {
> }
>
> QStringList InstrumentDTP41::possiblePorts() const
> {
> QStringList ports;
> ports << "COM1" << "COM2" << "COM3" << "COM4";
> return ports;
> }
|
|
From: Ruth Ivimey-C. <Rut...@iv...> - 2009-07-19 22:14:04
|
On Sunday 19 July 2009, Christoph Bartoschek wrote:
> Hi,
>
> could you please show the class InstrumentDTP41? Is multiple interitance
> involved?
Yes, but not straight away and the "multiple" is a pure-virtual.
This is the class that forms the Qt plugin interface. It's multiply inheriting, but this one appears to work ok.
-----------------------------------------
class GL_DTP41_EXPORT PluginDTP41: public QObject, public PluginInterface
{
Q_OBJECT;
Q_INTERFACES(PluginInterface);
public:
PluginDTP41();
virtual ~PluginDTP41();
virtual QStringList plugins() const;
virtual InstrumentInterface *createInstrument(QString plugin, const TargetDefBase *theTarget) const;
virtual void deleteInstrument(InstrumentInterface *i);
};
-----------------------------------------
And this is the one you asked about. It inherits singly from InstrumentBase, which is a class implementing the base functionality of InstrumentInterface, which is pure-virtual. However, InstrumentBase needs to be a QObject, so multiply-inherits QObject and the interface.
So:
InstrumentDTP41
: public InstrumentBase
: public QObject, public InstrumentInterface
-----------------------------------------
class InstrumentDTP41: public InstrumentBase
{
Q_OBJECT;
public:
virtual ~InstrumentDTP41();
InstrumentDTP41(const TargetDefBase *theTarget);
virtual bool ReadTarget(QString &colorant);
virtual QStringList possiblePorts() const;
private:
};
-----------------------------------------
Even the definition of InstrumentBase is big, but this is part of it...
-----------------------------------------
class InstrumentBase: public QObject, public InstrumentInterface
{
Q_OBJECT;
protected:
InstrumentReadMode readMode;
QString portType;
QString portParams;
MeasurementTypes measurementType;
IlluminantTypes illuminant;
QString instrumentName;
QString instrumentSerialNo;
QString instrumentVersion;
const TargetDefBase *target;
MeasurementCollection *densities;
public:
typedef QList<InstrumentCommand> InstrumentCommandList;
InstrumentBase(const TargetDefBase *theTarget);
virtual ~InstrumentBase();
virtual QStringList possiblePorts() const = 0;
virtual QString ToXML() const;
virtual ObserverAngles ObserverAngle() const
{
return OBS_NONE;
};
virtual QString InstrumentName() const
{
return instrumentName;
};
...
virtual void setPortParams(const QString &value)
{
portParams = value;
};
virtual bool Connect() { return true; };
virtual bool Disconnect() { return true; };
private:
Q_DISABLE_COPY(InstrumentBase);
};
-----------------------------------------
> Please also show InstrumentInterface.
It's pure a virtual interface definition:
-----------------------------------------
class InstrumentInterface
{
public:
typedef QList<InstrumentCommand> InstrumentCommandList;
virtual QStringList possiblePorts() const = 0;
virtual QString ToXML() const = 0;
virtual ObserverAngles ObserverAngle() const = 0;
virtual QString InstrumentName() const = 0;
virtual QString InstrumentVersion() const = 0;
virtual QString InstrumentSerialNo() const = 0;
virtual void setInstrumentSerialNo(QString serial) = 0;
virtual const TargetDefBase *Target() const = 0;
virtual void setTarget(TargetDefBase *value) = 0;
virtual MeasurementCollection *Densities() = 0;
virtual InstrumentReadMode ReadMode() const = 0;
virtual IlluminantTypes Illuminant() const = 0;
virtual void setIlluminant(IlluminantTypes value) = 0;
virtual MeasurementTypes MeasurementType() const = 0;
virtual void setMeasurementType(MeasurementTypes value) = 0;
virtual QString PortType() const = 0;
virtual void setPortType(QString value) = 0;
virtual QString PortParams() const = 0;
virtual void setPortParams(const QString &value) = 0;
virtual bool Connect() = 0;
virtual bool Disconnect() = 0;
virtual bool WriteData(QString &dat, int &lenWritten) = 0;
virtual bool ReadData(QString &dat, int numWanted, int &numGot, int timeout) = 0;
virtual bool CheckError() = 0;
virtual bool SendCommand(QString &cmd, SendErrorCheckMode errChk) = 0;
virtual bool SendCommands(InstrumentCommandList &commands, SendErrorCheckMode errChk) = 0;
virtual bool Configure() = 0;
virtual void EndReading() = 0;
virtual bool ReadTarget() = 0;
virtual bool ReadTarget(QString &colorant) = 0;
};
--
Engineer, Author and Webweaver
|
|
From: Ruth Ivimey-C. <Rut...@iv...> - 2009-07-19 21:21:28
|
Folks,
I'm hoping you can help. I'm writing a Qt4 program that uses the qt
plugin interface to implement loadable "instruments" reflecting
different hardware options. I use the Qt plugin interface to list,
create and delete instruments implemented by each plugin file.
The plugin creates the instrument fine, and the main program gets back
the pointer that "new" returned (as can be seen below in the
non-valgrind text: "New DTP" is in the plugin, "Created instrument" is
in the main program. The main program then deletes the instrument
"Deleting instrument"(by calling into the plugin again) and you can see
that the address remains the same "Delete DTP". I am at a loss as to why
valgrind (and the MS heap code) has "forgotten" this address ... it now
thinks (see line 1/2 way down log) that the original block address,
displayed here as 0x52990a0, was 0x5299090!
This log is from amd64/Fedora 10/valgrind 3.4.1. I've also tried this
code on 32-bit WinXP and on 64-bit Vista, they all fail, so something
bad is happening, but what? I tried a valgrind with a MC_MALLOC_REDZONE
size of 64 bytes to see if that changed anything, but it didn't show
anything different.
After the valgrind log entry I have appended code snippets: more on request.
New DTP @ 0x52990a0
Created instrument @ 0x52990a0 plugin @ 0xb398420
Deleting instrument @ 0x52990a0 plugin @ 0xb398420
Delete DTP @ 0x52990a0
==23127==
==23127== Invalid free() / delete / delete[]
==23127== at 0x4A05E4D: operator delete(void*)
(vg_replace_malloc.c:342)
==23127== by 0xB44772E:
PluginDTP41::deleteInstrument(InstrumentInterface*) (gl_dtp41.cpp:33)
==23127== by 0x43D674: SelectDevice::updateDeviceOptions()
(selectdevice.cpp:70)
==23127== by 0x443CFC: SelectDevice::qt_metacall(QMetaObject::Call,
int, void**) (moc_selectdevice.cpp:71)
==23127== by 0x3F3D559421: QMetaObject::activate(QObject*, int, int,
void**) (in /usr/lib64/libQtCore.so.4.5.1)
==23127== by 0x3F4B14A440: QComboBox::currentIndexChanged(int) (in
/usr/lib64/libQtGui.so.4.5.1)
==23127== by 0x3F4B14CAAB: (within /usr/lib64/libQtGui.so.4.5.1)
==23127== by 0x3F4B14E0D0: (within /usr/lib64/libQtGui.so.4.5.1)
==23127== by 0x3F4B14E21C: QComboBox::setCurrentIndex(int) (in
/usr/lib64/libQtGui.so.4.5.1)
==23127== by 0x3F4B15300A: QComboBox::qt_metacall(QMetaObject::Call,
int, void**) (in /usr/lib64/libQtGui.so.4.5.1)
==23127== by 0x3F3D559421: QMetaObject::activate(QObject*, int, int,
void**) (in /usr/lib64/libQtCore.so.4.5.1)
==23127== by 0x3F3D58FE13:
QAbstractItemModel::rowsInserted(QModelIndex const&, int, int) (in
/usr/lib64/libQtCore.so.4.5.1)
==23127== Address 0x52990a0 is 16 bytes inside a block of size 96
alloc'd
==23127== at 0x4A0700C: operator new(unsigned long)
(vg_replace_malloc.c:230)
==23127== by 0xB4473A4: PluginDTP41::createInstrument(QString,
TargetDefBase const*) const (gl_dtp41.cpp:25)
==23127== by 0x43CA8C: SelectDevice::CreateNewInstrument()
(selectdevice.cpp:43)
==23127== by 0x43D29F: SelectDevice::updateDeviceOptions()
(selectdevice.cpp:62)
==23127== by 0x443CFC: SelectDevice::qt_metacall(QMetaObject::Call,
int, void**) (moc_selectdevice.cpp:71)
==23127== by 0x3F3D559421: QMetaObject::activate(QObject*, int, int,
void**) (in /usr/lib64/libQtCore.so.4.5.1)
==23127== by 0x3F4B14A440: QComboBox::currentIndexChanged(int) (in
/usr/lib64/libQtGui.so.4.5.1)
==23127== by 0x3F4B14CAAB: (within /usr/lib64/libQtGui.so.4.5.1)
==23127== by 0x3F4B14E0D0: (within /usr/lib64/libQtGui.so.4.5.1)
==23127== by 0x3F4B14E21C: QComboBox::setCurrentIndex(int) (in
/usr/lib64/libQtGui.so.4.5.1)
==23127== by 0x3F4B15300A: QComboBox::qt_metacall(QMetaObject::Call,
int, void**) (in /usr/lib64/libQtGui.so.4.5.1)
==23127== by 0x3F3D559421: QMetaObject::activate(QObject*, int, int,
void**) (in /usr/lib64/libQtCore.so.4.5.1)
Code in the main program that is calling createInstrument and
deleteInstrument:
------------------------------------------------------
void SelectDevice::updateDeviceOptions(void)
{
if (instrument)
{
currentPlugin->deleteInstrument(instrument);
qDebug() << "Deleting instrument @" << instrument << " plugin @"
<< currentPlugin;
instrument = NULL;
}
m_ui->cbPort->clear();
knownPortTypes.clear();
// create an instrument so as to fetch the valid port types for it...
instrument = CreateNewInstrument();
qDebug() << "Created instrument @" << instrument << " plugin @" <<
currentPlugin;
if (instrument)
{
knownPortTypes = instrument->possiblePorts();
qDebug() << "Deleting instrument @" << instrument << " plugin @"
<< currentPlugin;
currentPlugin->deleteInstrument(instrument);
instrument = NULL;
m_ui->cbPort->addItems(knownPortTypes);
}
}
------------------------------------------------------
Code in the plugin that creates/deletes objects:
------------------------------------------------------
InstrumentInterface *PluginDTP41::createInstrument(QString plugin, const
TargetDefBase *theTarget) const
{
// no need to check "plugin" string at present.
InstrumentInterface *inst = new InstrumentDTP41(theTarget);
qDebug() << "New DTP @" << inst;
return inst;
}
void PluginDTP41::deleteInstrument(InstrumentInterface *inst)
{
qDebug() << "Delete DTP @" << inst;
delete inst;
}
------------------------------------------------------
Finally code in the plugin that is called in the middle:
------------------------------------------------------
InstrumentDTP41::InstrumentDTP41(const TargetDefBase *theTarget)
: InstrumentBase(theTarget)
{
instrumentName = "DTP-41";
srand( (unsigned)time( NULL ) );
}
InstrumentDTP41::~InstrumentDTP41(void)
{
}
QStringList InstrumentDTP41::possiblePorts() const
{
QStringList ports;
ports << "COM1" << "COM2" << "COM3" << "COM4";
return ports;
}
--
Engineer, Author and Webweaver
|
|
From: Madhan S. <mad...@gm...> - 2009-07-17 17:25:09
|
Hello, Is there a way to make every "Invalid read" and "Invalid write" result in a SIGSEGV. This will let my application create beautiful debug dumps that people love. Attaching debugger on error is not very suitable in automated nightly test runs. Thanks, Madhan. S |
|
From: John R. <jr...@bi...> - 2009-07-17 15:08:15
|
Nicholas Nethercote wrote:
> On Fri, Jul 17, 2009 at 2:16 AM, Zachary Turner<div...@gm...> wrote:
>> --track-origins=yes I find that the memory it's claiming is
>> uninitialized comes from sbrk(). As far as I can tell (please correct
>> me if I'm wrong) this function is guaranteed to return 0-filled
>> memory
> I'm not at all certain this is the case, which is why Memcheck marks
> it as undefined. Evidence to the contrary would be welcome!
0) sbrk() can *decrease* process address space. No zero fill is done
for a decrease, not even the fragment on the high end of the last page
that is beyond the new highest address. For maximum safety and
portability, then the bytes in the last page that reside above [the new]
sbrk(0) should be considered to be uninitialized, but in practice
it is exceedingly likely that they will retain their previous contents.
1) If an increase is large enough to require new whole pages,
then those new whole pages (like all new pages) are zero-filled
by the operating system. So if sbrk(0) already is page aligned,
then sbrk(PAGE_SIZE) *does* zero-fill the new memory.
2) Any increase that lies within an existing allocated page
is not changed. So if (x= sbrk(0)) is not page aligned, then
sbrk(PAGE_SIZE) yields ((PAGE_SIZE -1) & -x) bytes which
keep their existing contents, and an additional PAGE_SIZE
bytes which are zeroed. ((PAGE_SIZE -1) & x) of them are
"covered" by the sbrk(), and the rest of them come along for
the ride because the operating system deals only in whole pages.
Again, for maximum safety and portability, then anything that
lives above [the new] sbrk(0) should be considered uninitialized,
but in practice will retain previous contents [zero in this case.]
Also remember that sbrk(...) can fail :-)
--
|
|
From: Christophe-Marie D. <chm...@gm...> - 2009-07-17 14:59:17
|
Hi, While I'm waiting to be at home to test valgrind and covergrind, I browse the mail archive and I just found this almost 3 years old thread. Here are a few questions : - is covergrind still maintained (will the patch still apply)? - what does the "new output" look like (between beta1 and beta2)? -- Christophe-Marie Duquesne |
|
From: Christophe-Marie D. <chm...@gm...> - 2009-07-17 13:16:49
|
Hi, I am at work and I would like to checkout the last version of valgrind (in order to give a try to covergrind, I am being curious about this tool I just happened to discover). However, I am at work and the svn port is filtered by the sysadmins. Is there a http version of the repository? This would be nice... Best Regards, Christophe-Marie Duquesne |
|
From: Zachary T. <div...@gm...> - 2009-07-17 01:21:57
|
On Thu, Jul 16, 2009 at 7:47 PM, Nicholas Nethercote<n.n...@gm...> wrote: > On Fri, Jul 17, 2009 at 2:16 AM, Zachary Turner<div...@gm...> wrote: >> --track-origins=yes I find that the memory it's claiming is >> uninitialized comes from sbrk(). As far as I can tell (please correct >> me if I'm wrong) this function is guaranteed to return 0-filled >> memory > > I'm not at all certain this is the case, which is why Memcheck marks > it as undefined. Evidence to the contrary would be welcome! > > Nick > I'm not certain either :) When I google around it seems about 50/50 with some saying it does and some saying it doesn't. But it might be platform dependent. The glibc source code's implementation of malloc uses sbrk and has a comment that says "since sbrk() returns 0-filled memory, we don't need to initialize the entire buffer." or something to that effect. |
|
From: Nicholas N. <n.n...@gm...> - 2009-07-17 00:47:39
|
On Fri, Jul 17, 2009 at 2:16 AM, Zachary Turner<div...@gm...> wrote: > --track-origins=yes I find that the memory it's claiming is > uninitialized comes from sbrk(). As far as I can tell (please correct > me if I'm wrong) this function is guaranteed to return 0-filled > memory I'm not at all certain this is the case, which is why Memcheck marks it as undefined. Evidence to the contrary would be welcome! Nick |
|
From: Tom H. <to...@co...> - 2009-07-16 18:35:32
|
On 16/07/09 19:23, Tim Post wrote: > Then there's the corner case, when you are provided only with static > libs to link with. In that case, do what you can. However, that remains > a corner case :) There is no problem linking with static libraries in general, so long as you don't make the program completely static, and so long as the C library is dynamic so we can pick up malloc/free etc. Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Tim P. <ec...@ec...> - 2009-07-16 18:23:27
|
On Thu, 2009-07-16 at 11:16 -0500, Zachary Turner wrote: > Assuming this assessment is accurate, is it best to deal with this by > adding appropriate suppressions to the default suppressions file, or > by modifying valgrind to be smarter and know that sbrk memory is > always 0-filled? Its best to test without statically linking, then release after linking as you need. Doing the reverse hides bugs you really _want_ to know about. Valgrind is clever, but not psychic. Test with dynamic linkage, if that looks good, you have already ruled out the noise that production optimizations and static libs produce. Then there's the corner case, when you are provided only with static libs to link with. In that case, do what you can. However, that remains a corner case :) Cheers, --Tim |
|
From: Tom H. <to...@co...> - 2009-07-16 16:36:57
|
On 16/07/09 17:16, Zachary Turner wrote: > When I build any program (including an empty main function) using gcc > -static I get enormous amounts of errors in valgrind. After some > investigation and asking around I think that at least a large portion > of them are incorrect. In particular, I get many errors about > uninitialized memory and conditional jumps, but when I use > --track-origins=yes I find that the memory it's claiming is > uninitialized comes from sbrk(). As far as I can tell (please correct > me if I'm wrong) this function is guaranteed to return 0-filled > memory, so while it's true that the program is not explicitly > initializing, it should be initialized anyway. When you statically link a program you prevent valgrind from being able to intercept the malloc and free functions so you will find you get lots of warnings as a result. Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Zachary T. <div...@gm...> - 2009-07-16 16:17:06
|
When I build any program (including an empty main function) using gcc -static I get enormous amounts of errors in valgrind. After some investigation and asking around I think that at least a large portion of them are incorrect. In particular, I get many errors about uninitialized memory and conditional jumps, but when I use --track-origins=yes I find that the memory it's claiming is uninitialized comes from sbrk(). As far as I can tell (please correct me if I'm wrong) this function is guaranteed to return 0-filled memory, so while it's true that the program is not explicitly initializing, it should be initialized anyway. Assuming this assessment is accurate, is it best to deal with this by adding appropriate suppressions to the default suppressions file, or by modifying valgrind to be smarter and know that sbrk memory is always 0-filled? There are a number of other types of errors that seem to be generated quite commonly when using -static, but so far I have not been able to determine if those are harmless. |
|
From: Igmar P. <mai...@jd...> - 2009-07-15 14:32:40
|
> IS there any issues with installing Valgrind on HPNONSTOP (Tandem)? A non-supported OS and CPU. In other words : It won't work. Igmar |
|
From: Andy G. <and...@co...> - 2009-07-14 23:45:12
|
Thanks. The FAQ does explain it. It looks like my library is being unloaded before the app terminates in this case. Andy. On Jul 14, 2009, at 4:23 PM, Nicholas Nethercote wrote: > On Wed, Jul 15, 2009 at 7:51 AM, Andy > Grove<and...@co...> wrote: >> I saw earlier posts today where a user is not seeing source >> information in >> the valgrind output. I'm experiencing the same problem on one >> machine but >> not on another (with the same binary version of my library that I am >> testing). > > http://www.valgrind.org/docs/manual/faq.html#faq.unhelpful has some > more suggestions on this. > > Nick |
|
From: Nicholas N. <n.n...@gm...> - 2009-07-14 22:24:05
|
On Wed, Jul 15, 2009 at 7:51 AM, Andy Grove<and...@co...> wrote: > I saw earlier posts today where a user is not seeing source information in > the valgrind output. I'm experiencing the same problem on one machine but > not on another (with the same binary version of my library that I am > testing). http://www.valgrind.org/docs/manual/faq.html#faq.unhelpful has some more suggestions on this. Nick |
|
From: Andy G. <and...@co...> - 2009-07-14 22:11:58
|
I saw earlier posts today where a user is not seeing source information in the valgrind output. I'm experiencing the same problem on one machine but not on another (with the same binary version of my library that I am testing). Here is the output on the server that does not show the source information: ==3821== 195,899 bytes in 13,600 blocks are definitely lost in loss record 77 of 78 ==3821== at 0x4A06497: operator new[](unsigned long) (vg_replace_malloc.c:274) ==3821== by 0x9DFCB9D: ??? ==3821== by 0x9DFED2B: ??? ==3821== by 0x9E0EE41: ??? ==3821== by 0x9DFB9BD: ??? ==3821== by 0x9E10EB5: ??? ==3821== by 0x9E6FE46: ??? ==3821== by 0x9E673B6: ??? ==3821== by 0x9E4ECFA: ??? ==3821== by 0xAD2D3CC: ??? ==3821== by 0x5CEA11: zend_do_fcall_common_helper_SPEC (in /usr/bin/ php) ==3821== by 0x5BE80B: execute (in /usr/bin/php) My C library is called from PHP on both servers. Both servers are CentOS 5.2 but slightly different revisions. I'd like to know what I need to do to get the source/line number information to display on the server that is not currently displaying that information. I saw a suggestion about install debug versions if libstdc++ but I don't seem to have those installed on the server where this is working correctly. I'd appreciate any pointers on how to resolve this. Thanks, Andy. |
|
From: Gregory P. <gp...@pa...> - 2009-07-14 22:04:17
|
IS there any issues with installing Valgrind on HPNONSTOP (Tandem)? Thanks, G |
|
From: Ivan N. <nov...@gm...> - 2009-07-14 20:42:11
|
great, thanks! On Tue, Jul 14, 2009 at 1:02 PM, Tom Hughes<to...@co...> wrote: > On 14/07/09 20:21, Ivan Novick wrote: > >> I am getting: >> >> WARNING: unhandled syscall: 142 >> >> My machine is Ubuntu: Linux paloalto 2.6.27-9-generic #1 SMP Thu Nov >> 20 22:15:32 UTC 2008 x86_64 GNU/Linux >> >> Is system call 142 handled in the most recent codebase of valgrind? > > That's sched_setparam and the current svn code certainly handles it. > > Tom > > -- > Tom Hughes (to...@co...) > http://www.compton.nu/ > |
|
From: Tom H. <to...@co...> - 2009-07-14 20:01:53
|
On 14/07/09 20:21, Ivan Novick wrote: > I am getting: > > WARNING: unhandled syscall: 142 > > My machine is Ubuntu: Linux paloalto 2.6.27-9-generic #1 SMP Thu Nov > 20 22:15:32 UTC 2008 x86_64 GNU/Linux > > Is system call 142 handled in the most recent codebase of valgrind? That's sched_setparam and the current svn code certainly handles it. Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: John R.
|
> I'm also not using the most recent > version of Valgrind, I'm using 3.1.x, is there a huge difference? Yes, there is a *huge* difference: three years worth of work. valgrind-3.1.1: 15 March 2006 valgrind-3.4.1: 28 February 2009 -- |