Issue: MDNS server initially sends probing packets to resolve naming confilicts with already registered service instances. In case of a conflict, instance name is altered and probing restarts. Original instance however wasnnot removed from the structure and upon service removal only one entry was removed and a dangling service might have been kept in the structure to bring about a crash.
Resolution: Keep only one instance of a service in the probing structure.
Closes IDF-438
possible race condition: user task runs mdns_init, which enables pcbs while mdns-task already created could execute enable/disable of the same pcbs if an appropriate system event received
mnds_free() initiates stop and delete timer tasks, which after locking the mutex could lead to a dead lock in case timer task executed before deleting the task, as it would wait indefinitelly for unlocking the mutex. This condition is fixed by calling _mdns_stop_timer without locking the mutex, because there's no need to protect any data when stopping and deleting the timer task
Closes https://github.com/espressif/esp-idf/issues/1696
Issue: mdns_service_add API allocates and queues an action to be processed in mdns task context; when allocation or queueing fails, allocated structure needs to be freed. Function _mdns_free_service did not only fee all the structures, but also updates packet data.
Resolution: Moved removal of packet data outside of _mdns_free_service function.
packets scheduled to transmit are pushed to action queue and removed from tx_queue_head structure, which is searched for all remaining services and while service is removed, then service questions/asnwers are also removed from this structure. This update fixes possible crash when packet is pushed to action queue, and when service is removed, its answers are removed from tx_queue_head, but not from action queue. this could lead to a crash when the packet is poped from action queue containing questions/answers to already removed (freed) service
Closes IDF-438
mdns_search_once_t::lock is used to synchronize tasks (taken by one
task and given by the other) so it should not be a mutex.
Convert to semaphore, and rename to indicate its purpose.
When generating JSON metadata for ranges where there are conditional ranges (ie different allowed range
depending on another config setting), the JSON metadata would always have the last named range as
the expression was not evaluated properly.
Thanks to ulfalizer on GitHub for pointing this out.
Closes https://github.com/espressif/esp-idf/issues/2195
By default, if a URI handler changes the http session context,
the webserver internally clears the older context after the handler
returns. However, if applications want to change this behavior and
manage the allocation/de-allocation/freeing themselves and let the
server handle only the "socket close" case, this commit provides such
an option.
When xPortGetCoreID() is called twice within a function,
it might only be called once after compilation. This
commit makes the inline assembly of the function volatile.
Closes#3093
Previously when HashList was removing items, HashListBlocks were
removed lazily. This resulted in empty HashListBlocks dangling around
in full pages, even when all items have been erased. These blocks
would only be deleted when NVS was re-initialized
(nvs_flash_deinit/nvs_flash_init).
This change does eager cleanup instead, based on the code from
@negativekelvin offered in
https://github.com/espressif/esp-idf/issues/1642#issuecomment-367227994.
Closes https://github.com/espressif/esp-idf/issues/1642.
1. ref_clock used in unit tests occasionally produces time off by ~100
microseconds shortly after being started. Add a delay to let
ref_clock stabilise, until the cause is found.
2. Reduce roundoff error accumulation which would occasionally cause
the test to fail, by choosing an overflow value which can be divided
by APB frequency.
3. Move time sampling part of the test into an IRAM function to
reduce variations due to cache behavior.
4. Remove calculation of "standard deviation" in the test, as what was
calculated was not actually standard deviation, and it did not add any
useful information.
1. call esp_timer_get_time and ref_clock_get in the same order on
start and in the loop
2. disable interrupts when calculating delta between ref_clock
and esp_timer
3. ensure both functions are in cache before calculating the delta
In the situation when bootloader was compiled for 240MHz, and app was
compiled for 160MHz, and the chip is a revision 0 chip, the
bootloader will assume that the application has also been running at
240MHz. This will cause the chip to lock up later. Modify this to use
a run time check of DPORT_CPUPERIOD_SEL, which indicates which of the
PLL frequencies was used.
Closes https://github.com/espressif/esp-idf/issues/2731.
1. When one of the COMPONENT_DIRS points to a component directory
(i.e. a directory containing component.mk, not a directory of multiple
components), and there is a subdirectory in it which also contains
a component, the subdirectory was mistakenly added to the list of
components and compiled.
For example:
main/
component.mk
main.c
test/
component.mk
test_main.c
Would compile test_main.c and link libtest.a.
2. When one of the COMPONENT_DIRS points to a component directory, and
the parent directory contained a directory with the same name as
another component, that directory would be mistakenly added to the
COMPONENT_PATHS.
For example:
esp/
esp-idf/
esp32/
(random stuff)
mycomponent/
component.mk
mycomponent.c
myproject/
main/
Makefile
and Makefile sets EXTRA_COMPONENT_DIRS=$(realpath ../mycomponent),
then "esp32" directory which is at the same level as mycomponent
was added to COMPONENT_PATHS.
3. If EXTRA_COMPONENT_DIRS pointed to a directory with a list of
components, and one of the subdirectories was not a component, but
had the same name as another component, than that directory would be
mistakenly added to COMPONENT_PATHS instead of the real esp32
component directory.
For example:
my_components/
my_component/
component.mk
my_component.c
esp32/
(some random stuff)
and EXTRA_COMPONENT_DIRS would point to my_components/, then "esp32"
directory would be added to COMPONENT_PATHS instead of the real esp32
component directory.
Previously, this compiler flag was not being applied
regardless of CONFIG_SPIRAM_CACHE_WORKAROUND setting.
Explanation: add_compile_options() only applies to
source files added after the function is run, or in
subdirectories added after the function is run. In
this case, no new source files were being added after
this function was run.